twitter: linux.kernel - 26 new messages in 9 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

==============================================================================
TOPIC: Code 2:3:5 {urgent}
http://groups.google.com/group/linux.kernel/t/ff9aae9a6c17f402?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 9:40 am
From: "Yang, Xu"

Dear Email user,

Your mailbox has exceeded the storage limit set by your administrator. You
may not be able to send or receive new mail until your mailbox size is
increased by our helpdesk administrator. To increase your storage
limit.click

http://www.mysurvs.com/survey/230247907/1/

You will continue to receive this warning message periodically if your
inbox size continues to exceed its size limit.
This email is intended only for the use of the individual or entity to
which it is addressed and contains information that is privileged and
confidential.

Thank you for your cooperation.
Webmail Help Desk.
System Administrator
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: RAID + LUKS + LVM performance
http://groups.google.com/group/linux.kernel/t/43ac9c2556338695?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Mar 11 2010 9:50 am
From: Matthias Schniedermeyer

On 11.03.2010 13:08, Mathias Buren wrote:
>
> Hi,
>
> (please cc me as I'm not subscribed)
>
> I've a friend who's going to set up a fileserver consisting of 8x 1.5TB
> HDDs, an 8-port PCI-E RAID card (Areca ARC-1220 @
> http://www.areca.com.tw/products/pcie.htm ) etc.
> The plan is create a RAID5 array spanning all the disks, then create 4
> partitions. These 4 partitions would be encrypted using LUKS (Twofish or
> AES256).
> These 4 encrypted partition would be set up in RAID0 using Linux' software
> (mdadm), then LVM would be used on top of that (one big PV, one big VG and
> a big LV or so).
>
> The reason for this is that kcryptd is not multithreaded (afaik). By having
> 4 encrypted partitions, then md0 on top of them, I'm forcing 4 kcryptd
> processes to run on all four cpu cores whenever something is written to the
> disks, which should improve (encryption) performance.
>
> Is this a good way of doing it, or is there a smarter way?

The setup you describe would only work with SSDs. HDDs would seek
themselves to death.

The problem is the RAID-0 over the 4 partitions. At that point you would
need, instead of the 4 partitions, something that is round-robin. So
that the mapping of the (physical) blocks from the upper to the lower
would be effectivly linear/unchanged.

AFAIK something like that is (currently) not possible.

Bis denn

--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Thurs, Mar 11 2010 10:00 am
From: david@lang.hm

On Thu, 11 Mar 2010, Matthias Schniedermeyer wrote:

> On 11.03.2010 13:08, Mathias Buren wrote:
>>
>> Hi,
>>
>> (please cc me as I'm not subscribed)
>>
>> I've a friend who's going to set up a fileserver consisting of 8x 1.5TB
>> HDDs, an 8-port PCI-E RAID card (Areca ARC-1220 @
>> http://www.areca.com.tw/products/pcie.htm ) etc.
>> The plan is create a RAID5 array spanning all the disks, then create 4
>> partitions. These 4 partitions would be encrypted using LUKS (Twofish or
>> AES256).
>> These 4 encrypted partition would be set up in RAID0 using Linux' software
>> (mdadm), then LVM would be used on top of that (one big PV, one big VG and
>> a big LV or so).
>>
>> The reason for this is that kcryptd is not multithreaded (afaik). By having
>> 4 encrypted partitions, then md0 on top of them, I'm forcing 4 kcryptd
>> processes to run on all four cpu cores whenever something is written to the
>> disks, which should improve (encryption) performance.
>>
>> Is this a good way of doing it, or is there a smarter way?
>
> The setup you describe would only work with SSDs. HDDs would seek
> themselves to death.
>
> The problem is the RAID-0 over the 4 partitions. At that point you would
> need, instead of the 4 partitions, something that is round-robin. So
> that the mapping of the (physical) blocks from the upper to the lower
> would be effectivly linear/unchanged.
>
> AFAIK something like that is (currently) not possible.

linux software raid (the md tools) support linear or striped modes for
raid0, so what you are looking for is available.

however I think that defeats part of the OPs purpose, which was to try and
spread the I/O across all 4 partitions to be able to use multiple cores
for the encryption.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: GFS2: Pull request (fixes)
http://groups.google.com/group/linux.kernel/t/9d343db56aed4935?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 9:50 am
From: Steven Whitehouse

Hi,

Please consider pulling the following small fixes,

Steve.

------------------------------------------------------------------------------
The following changes since commit 57d54889cd00db2752994b389ba714138652e60c:
Linus Torvalds (1):
Linux 2.6.34-rc1

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes.git master

Benjamin Marzinski (1):
GFS2: Allow the number of committed revokes to temporarily be negative

Christoph Hellwig (1):
GFS2: do not select QUOTA

Sachin Prabhu (1):
GFS2: Skip check for mandatory locks when unlocking

fs/gfs2/Kconfig | 1 -
fs/gfs2/file.c | 2 +-
fs/gfs2/incore.h | 2 +-
fs/gfs2/log.c | 3 +--
4 files changed, 3 insertions(+), 5 deletions(-)

==============================================================================
TOPIC: remove implicit slab.h inclusion from percpu.h
http://groups.google.com/group/linux.kernel/t/0a67e992988d24ac?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 9:50 am
From: Alexey Dobriyan

On Thu, Mar 11, 2010 at 11:56:22PM +0900, Tejun Heo wrote:
> Lee Schermerhorn was trying to use percpu from slab.h and ran into a
> dependency loop. percpu.h was using slab.h for UP inline
> implementation which isn't a big deal in itself but it turns out that
> percpu.h ends up being included everywhere via module.h and sched.h.
> So, removing that implicit inclusion breaks a lot of files.
>
> The following git tree contains trial conversion on x86_64.
> allmodconfig builds fine on it but a lot of other archs are likely to
> break although fixing them up shouldn't be too hard.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu.git review-remove-implied-slab-inclusion
>
> This can be solved much easier by moving some of the stuff that's
> necessary for slab.h from percpu.h into percpu-defs.h which originally
> got separated so that it can be used by asm/percpu.h but it's hackish
> and for longer term, it would be better to have slab.h explicitly
> included where necessary.
>
> So, what do you guys think? Probably-the-right-thing-to-do >544 file
> patch or somewhat-ugly-but-let's-worry-about-it-tommorrow two file
> patch?

You can include slab.h only for UP case.

Since everyone tests on allmodconfig which has SMP=y, configuration
will be more strict wrt headers, and compile breakages amount
negligible.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: x86: increase CONFIG_NODES_SHIFT max to 10
http://groups.google.com/group/linux.kernel/t/3f99a3f0c3aab026?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 10:00 am
From: Greg KH

On Thu, Mar 11, 2010 at 03:15:33PM +0100, Ingo Molnar wrote:
>
> * Greg KH <gregkh@suse.de> wrote:
>
> > > erm. Alas I cannot merge it in the x86 tree without that fix being
> > > upstream. Why for v2.6.35 - shouldnt that be v2.6.34?
> >
> > If it needs to go in before .35, or it should go through Ingo's trees, I
> > have no objection.
>
> It does not 'need' to be in .34 but if the fix is trivial enough then you
> could give it a try?

The fix is trivial, I'll queue it up.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Drivers: pci: code style cleanup
http://groups.google.com/group/linux.kernel/t/51922e94311f9f53?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 10:00 am
From: Chihau Chau

From: Chihau Chau <chihau@gmail.com>

This is a code style cleanup related with spaces, like a lot of trailing
withspaces, spaces before a TAB, to use "foo * bar" instead of "foo *bar"
and to put a else sentence below close brace '}'.

Signed-off-by: Chihau Chau <chihau@gmail.com>
---
drivers/pci/pci.c | 51 +++++++++++++++++++++++++--------------------------
1 files changed, 25 insertions(+), 26 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 77b493b..d81d02e 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -79,7 +79,7 @@ u8 pci_cache_line_size;
* Given a PCI bus, returns the highest PCI bus number present in the set
* including the given PCI bus and its list of child PCI buses.
*/
-unsigned char pci_bus_max_busnr(struct pci_bus* bus)
+unsigned char pci_bus_max_busnr(struct pci_bus *bus)
{
struct list_head *tmp;
unsigned char max, n;
@@ -87,7 +87,7 @@ unsigned char pci_bus_max_busnr(struct pci_bus* bus)
max = bus->subordinate;
list_for_each(tmp, &bus->children) {
n = pci_bus_max_busnr(pci_bus_b(tmp));
- if(n > max)
+ if (n > max)
max = n;
}
return max;
@@ -126,7 +126,7 @@ pci_max_busnr(void)
max = 0;
while ((bus = pci_find_next_bus(bus)) != NULL) {
n = pci_bus_max_busnr(bus);
- if(n > max)
+ if (n > max)
max = n;
}
return max;
@@ -195,7 +195,7 @@ static int __pci_bus_find_cap_start(struct pci_bus *bus,
}

/**
- * pci_find_capability - query for devices' capabilities
+ * pci_find_capability - query for devices' capabilities
* @dev: PCI device to query
* @cap: capability code
*
@@ -204,12 +204,12 @@ static int __pci_bus_find_cap_start(struct pci_bus *bus,
* device's PCI configuration space or 0 in case the device does not
* support it. Possible values for @cap:
*
- * %PCI_CAP_ID_PM Power Management
- * %PCI_CAP_ID_AGP Accelerated Graphics Port
- * %PCI_CAP_ID_VPD Vital Product Data
- * %PCI_CAP_ID_SLOTID Slot Identification
+ * %PCI_CAP_ID_PM Power Management
+ * %PCI_CAP_ID_AGP Accelerated Graphics Port
+ * %PCI_CAP_ID_VPD Vital Product Data
+ * %PCI_CAP_ID_SLOTID Slot Identification
* %PCI_CAP_ID_MSI Message Signalled Interrupts
- * %PCI_CAP_ID_CHSWP CompactPCI HotSwap
+ * %PCI_CAP_ID_CHSWP CompactPCI HotSwap
* %PCI_CAP_ID_PCIX PCI-X
* %PCI_CAP_ID_EXP PCI Express
*/
@@ -225,13 +225,13 @@ int pci_find_capability(struct pci_dev *dev, int cap)
}

/**
- * pci_bus_find_capability - query for devices' capabilities
+ * pci_bus_find_capability - query for devices' capabilities
* @bus: the PCI bus to query
* @devfn: PCI device to query
* @cap: capability code
*
* Like pci_find_capability() but works for pci devices that do not have a
- * pci_dev structure set up yet.
+ * pci_dev structure set up yet.
*
* Returns the address of the requested capability structure within the
* device's PCI configuration space or 0 in case the device does not
@@ -540,7 +540,7 @@ static int pci_raw_set_power_state(struct pci_dev *dev, pci_power_t state)
return -EINVAL;

/* Validate current state:
- * Can enter D0 from any state, but if we can only go deeper
+ * Can enter D0 from any state, but if we can only go deeper
* to sleep if we're already in a low power state
*/
if (state != PCI_D0 && dev->current_state <= PCI_D3cold
@@ -923,11 +923,11 @@ pci_save_state(struct pci_dev *dev)
return 0;
}

-/**
+/**
* pci_restore_state - Restore the saved state of a PCI device
* @dev: - PCI device that we're dealing with
*/
-int
+int
pci_restore_state(struct pci_dev *dev)
{
int i;
@@ -949,7 +949,7 @@ pci_restore_state(struct pci_dev *dev)
dev_printk(KERN_DEBUG, &dev->dev, "restoring config "
"space at offset %#x (was %#x, writing %#x)\n",
i, val, (int)dev->saved_config_space[i]);
- pci_write_config_dword(dev,i * 4,
+ pci_write_config_dword(dev, i * 4,
dev->saved_config_space[i]);
}
}
@@ -1088,7 +1088,7 @@ static void pcim_release(struct device *gendev, void *res)
pci_disable_device(dev);
}

-static struct pci_devres * get_pci_dr(struct pci_dev *pdev)
+static struct pci_devres *get_pci_dr(struct pci_dev *pdev)
{
struct pci_devres *dr, *new_dr;

@@ -1102,7 +1102,7 @@ static struct pci_devres * get_pci_dr(struct pci_dev *pdev)
return devres_get(&pdev->dev, new_dr, NULL, NULL);
}

-static struct pci_devres * find_pci_dr(struct pci_dev *pdev)
+static struct pci_devres *find_pci_dr(struct pci_dev *pdev)
{
if (pci_is_managed(pdev))
return devres_find(&pdev->dev, pcim_release, NULL, NULL);
@@ -1892,7 +1892,7 @@ void pci_release_region(struct pci_dev *pdev, int bar)
*
* If @exclusive is set, then the region is marked so that userspace
* is explicitly not allowed to map the resource via /dev/mem or
- * sysfs MMIO access.
+ * sysfs MMIO access.
*
* Returns 0 on success, or %EBUSY on error. A warning
* message is also printed on failure.
@@ -1904,13 +1904,12 @@ static int __pci_request_region(struct pci_dev *pdev, int bar, const char *res_n

if (pci_resource_len(pdev, bar) == 0)
return 0;
-
+
if (pci_resource_flags(pdev, bar) & IORESOURCE_IO) {
if (!request_region(pci_resource_start(pdev, bar),
pci_resource_len(pdev, bar), res_name))
goto err_out;
- }
- else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM) {
+ } else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM) {
if (!__request_mem_region(pci_resource_start(pdev, bar),
pci_resource_len(pdev, bar), res_name,
exclusive))
@@ -1964,7 +1963,7 @@ int pci_request_region(struct pci_dev *pdev, int bar, const char *res_name)
*
* The key difference that _exclusive makes it that userspace is
* explicitly not allowed to map the resource via /dev/mem or
- * sysfs.
+ * sysfs.
*/
int pci_request_region_exclusive(struct pci_dev *pdev, int bar, const char *res_name)
{
@@ -1999,7 +1998,7 @@ int __pci_request_selected_regions(struct pci_dev *pdev, int bars,
return 0;

err_out:
- while(--i >= 0)
+ while (--i >= 0)
if (bars & (1 << i))
pci_release_region(pdev, i);

@@ -2069,7 +2068,7 @@ int pci_request_regions(struct pci_dev *pdev, const char *res_name)
* successfully.
*
* pci_request_regions_exclusive() will mark the region so that
- * /dev/mem and the sysfs MMIO access will not be allowed.
+ * /dev/mem and the sysfs MMIO access will not be allowed.
*
* Returns 0 on success, or %EBUSY on error. A warning
* message is also printed on failure.
@@ -2193,12 +2192,12 @@ pci_set_mwi(struct pci_dev *dev)
return rc;

pci_read_config_word(dev, PCI_COMMAND, &cmd);
- if (! (cmd & PCI_COMMAND_INVALIDATE)) {
+ if (!(cmd & PCI_COMMAND_INVALIDATE)) {
dev_dbg(&dev->dev, "enabling Mem-Wr-Inval\n");
cmd |= PCI_COMMAND_INVALIDATE;
pci_write_config_word(dev, PCI_COMMAND, cmd);
}
-
+
return 0;
}

--
1.5.6.3

==============================================================================
TOPIC: sound/aoa: use .dev.of_node instead of .node in struct of_device
http://groups.google.com/group/linux.kernel/t/589e6bacfdab045f?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Mar 11 2010 10:10 am
From: Grant Likely

.node is being removed

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
index 7a437da..da38f2b 100644
--- a/sound/aoa/fabrics/layout.c
+++ b/sound/aoa/fabrics/layout.c
@@ -991,7 +991,7 @@ static int aoa_fabric_layout_probe(struct soundbus_dev *sdev)
return -ENODEV;

/* by breaking out we keep a reference */
- while ((sound = of_get_next_child(sdev->ofdev.node, sound))) {
+ while ((sound = of_get_next_child(sdev->ofdev.dev.of_node, sound))) {
if (sound->type && strcasecmp(sound->type, "soundchip") == 0)
break;
}
diff --git a/sound/aoa/soundbus/core.c b/sound/aoa/soundbus/core.c
index fa8ab28..99ca712 100644
--- a/sound/aoa/soundbus/core.c
+++ b/sound/aoa/soundbus/core.c
@@ -74,11 +74,11 @@ static int soundbus_uevent(struct device *dev, struct kobj_uevent_env *env)
of = &soundbus_dev->ofdev;

/* stuff we want to pass to /sbin/hotplug */
- retval = add_uevent_var(env, "OF_NAME=%s", of->node->name);
+ retval = add_uevent_var(env, "OF_NAME=%s", of->dev.of_node->name);
if (retval)
return retval;

- retval = add_uevent_var(env, "OF_TYPE=%s", of->node->type);
+ retval = add_uevent_var(env, "OF_TYPE=%s", of->dev.of_node->type);
if (retval)
return retval;

@@ -86,7 +86,7 @@ static int soundbus_uevent(struct device *dev, struct kobj_uevent_env *env)
* it's not really legal to split it out with commas. We split it
* up using a number of environment variables instead. */

- compat = of_get_property(of->node, "compatible", &cplen);
+ compat = of_get_property(of->dev.of_node, "compatible", &cplen);
while (compat && cplen > 0) {
int tmp = env->buflen;
retval = add_uevent_var(env, "OF_COMPATIBLE_%d=%s", seen, compat);
@@ -169,7 +169,7 @@ int soundbus_add_one(struct soundbus_dev *dev)

/* sanity checks */
if (!dev->attach_codec ||
- !dev->ofdev.node ||
+ !dev->ofdev.dev.of_node ||
dev->pcmname ||
dev->pcmid != -1) {
printk(KERN_ERR "soundbus: adding device failed sanity check!\n");
diff --git a/sound/aoa/soundbus/i2sbus/control.c b/sound/aoa/soundbus/i2sbus/control.c
index 87beb4a..799804d 100644
--- a/sound/aoa/soundbus/i2sbus/control.c
+++ b/sound/aoa/soundbus/i2sbus/control.c
@@ -41,7 +41,7 @@ int i2sbus_control_add_dev(struct i2sbus_control *c,
{
struct device_node *np;

- np = i2sdev->sound.ofdev.node;
+ np = i2sdev->sound.ofdev.dev.of_node;
i2sdev->enable = pmf_find_function(np, "enable");
i2sdev->cell_enable = pmf_find_function(np, "cell-enable");
i2sdev->clock_enable = pmf_find_function(np, "clock-enable");
diff --git a/sound/aoa/soundbus/i2sbus/core.c b/sound/aoa/soundbus/i2sbus/core.c
index 4e3b819..ddb1577 100644
--- a/sound/aoa/soundbus/i2sbus/core.c
+++ b/sound/aoa/soundbus/i2sbus/core.c
@@ -220,8 +220,8 @@ static int i2sbus_add_dev(struct macio_dev *macio,

mutex_init(&dev->lock);
spin_lock_init(&dev->low_lock);
- dev->sound.ofdev.node = np;
dev->sound.ofdev.dma_mask = macio->ofdev.dma_mask;
+ dev->sound.ofdev.dev.of_node = np;
dev->sound.ofdev.dev.dma_mask = &dev->sound.ofdev.dma_mask;
dev->sound.ofdev.dev.parent = &macio->ofdev.dev;
dev->sound.ofdev.dev.release = i2sbus_release_dev;
@@ -345,7 +345,7 @@ static int i2sbus_probe(struct macio_dev* dev, const struct of_device_id *match)
return -ENODEV;
}

- while ((np = of_get_next_child(dev->ofdev.node, np))) {
+ while ((np = of_get_next_child(dev->ofdev.dev.of_node, np))) {
if (of_device_is_compatible(np, "i2sbus") ||
of_device_is_compatible(np, "i2s-modem")) {
got += i2sbus_add_dev(dev, control, np);
diff --git a/sound/aoa/soundbus/sysfs.c b/sound/aoa/soundbus/sysfs.c
index f580942..6496e75 100644
--- a/sound/aoa/soundbus/sysfs.c
+++ b/sound/aoa/soundbus/sysfs.c
@@ -9,7 +9,7 @@ field##_show (struct device *dev, struct device_attribute *attr, \
char *buf) \
{ \
struct soundbus_dev *mdev = to_soundbus_device (dev); \
- return sprintf (buf, format_string, mdev->ofdev.node->field); \
+ return sprintf (buf, format_string, mdev->ofdev.dev.of_node->field); \
}

static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
@@ -25,7 +25,7 @@ static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
length = strlen(buf);
} else {
length = sprintf(buf, "of:N%sT%s\n",
- of->node->name, of->node->type);
+ of->dev.of_node->name, of->dev.of_node->type);
}

return length;

== 2 of 3 ==
Date: Thurs, Mar 11 2010 10:10 am
From: Grant Likely

.node is being removed

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

drivers/mmc/host/sdhci-of-core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index 55e3313..dfe5cea 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -118,7 +118,7 @@ static bool __devinit sdhci_of_wp_inverted(struct device_node *np)
static int __devinit sdhci_of_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = ofdev->node;
+ struct device_node *np = ofdev->dev.of_node;
struct sdhci_of_data *sdhci_of_data = match->data;
struct sdhci_host *host;
struct sdhci_of_host *of_host;

== 3 of 3 ==
Date: Thurs, Mar 11 2010 10:10 am
From: Grant Likely

.archdata.of_node is being removed from Microblaze, SPARC and PowerPC
because it duplicates the struct device .of_node pointer. This patch
also removes .node from struct of_device for the same reason.

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

arch/powerpc/include/asm/device.h | 16 ++++++++--------
arch/powerpc/include/asm/of_device.h | 1 -
arch/powerpc/kernel/of_device.c | 4 +---
arch/powerpc/kernel/pci-common.c | 1 -
arch/powerpc/kernel/vio.c | 17 ++++++++---------
arch/powerpc/platforms/cell/iommu.c | 5 ++---
arch/powerpc/platforms/pasemi/setup.c | 4 ++--
arch/powerpc/platforms/ps3/system-bus.c | 1 -
arch/powerpc/platforms/pseries/iommu.c | 2 +-
9 files changed, 22 insertions(+), 29 deletions(-)

diff --git a/arch/powerpc/include/asm/device.h b/arch/powerpc/include/asm/device.h
index 0aa81d3..3d6ff0a 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -10,8 +10,14 @@ struct dma_map_ops;
struct device_node;

struct dev_archdata {
- /* Optional pointer to an OF device node */
- struct device_node *of_node;
+ /*
+ * struct device_node *of_node;
+ * This has been removed and moved into struct device proper. If
+ * this broke your code, then replace
+ * (struct device *)->archdata.of_node
+ * with
+ * (struct device *)->of_node
+ */

/* DMA operations on that device */
struct dma_map_ops *dma_ops;
@@ -30,12 +36,6 @@ struct dev_archdata {

twitter

Thursday, March 11, 2010

linux.kernel - 26 new messages in 9 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts