* [PATCH v2 1/4] [libata] pata_platform: make probe and remove functions device type neutral
From: Anton Vorontsov @ 2007-12-04 17:06 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
Cc: Jeff Garzik, Arnd Bergmann, Paul Mundt, Olof Johansson
In-Reply-To: <20071204170442.GA10460@localhost.localdomain>
Split pata_platform_{probe,remove} into two pieces:
1. pata_platform_{probe,remove} -- platform_device-dependant bits;
2. __ptata_platform_{probe,remove} -- device type neutral bits.
This is done to not duplicate code for the OF-platform driver.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/ata/pata_platform.c | 143 ++++++++++++++++++++++++-----------------
include/linux/pata_platform.h | 9 +++
2 files changed, 94 insertions(+), 58 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index ac03a90..d4cb231 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -93,14 +93,9 @@ static struct ata_port_operations pata_platform_port_ops = {
};
static void pata_platform_setup_port(struct ata_ioports *ioaddr,
- struct pata_platform_info *info)
+ unsigned int shift)
{
- unsigned int shift = 0;
-
/* Fixup the port shift for platforms that need it */
- if (info && info->ioport_shift)
- shift = info->ioport_shift;
-
ioaddr->data_addr = ioaddr->cmd_addr + (ATA_REG_DATA << shift);
ioaddr->error_addr = ioaddr->cmd_addr + (ATA_REG_ERR << shift);
ioaddr->feature_addr = ioaddr->cmd_addr + (ATA_REG_FEATURE << shift);
@@ -114,8 +109,12 @@ static void pata_platform_setup_port(struct ata_ioports *ioaddr,
}
/**
- * pata_platform_probe - attach a platform interface
- * @pdev: platform device
+ * __pata_platform_probe - attach a platform interface
+ * @dev: device
+ * @io_res: Resource representing I/O base
+ * @ctl_res: Resource representing CTL base
+ * @irq_res: Resource representing IRQ and its flags
+ * @ioport_shift: I/O port shift
*
* Register a platform bus IDE interface. Such interfaces are PIO and we
* assume do not support IRQ sharing.
@@ -135,42 +134,18 @@ static void pata_platform_setup_port(struct ata_ioports *ioaddr,
*
* If no IRQ resource is present, PIO polling mode is used instead.
*/
-static int __devinit pata_platform_probe(struct platform_device *pdev)
+int __devinit __pata_platform_probe(struct device *dev,
+ struct resource *io_res,
+ struct resource *ctl_res,
+ struct resource *irq_res,
+ unsigned int ioport_shift,
+ int __pio_mask)
{
- struct resource *io_res, *ctl_res;
struct ata_host *host;
struct ata_port *ap;
- struct pata_platform_info *pp_info;
unsigned int mmio;
- int irq;
-
- /*
- * Simple resource validation ..
- */
- if ((pdev->num_resources != 3) && (pdev->num_resources != 2)) {
- dev_err(&pdev->dev, "invalid number of resources\n");
- return -EINVAL;
- }
-
- /*
- * Get the I/O base first
- */
- io_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (io_res == NULL) {
- io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (unlikely(io_res == NULL))
- return -EINVAL;
- }
-
- /*
- * Then the CTL base
- */
- ctl_res = platform_get_resource(pdev, IORESOURCE_IO, 1);
- if (ctl_res == NULL) {
- ctl_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (unlikely(ctl_res == NULL))
- return -EINVAL;
- }
+ int irq = 0;
+ int irq_flags = 0;
/*
* Check for MMIO
@@ -181,20 +156,21 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
/*
* And the IRQ
*/
- irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- irq = 0; /* no irq */
+ if (irq_res && irq_res->start > 0) {
+ irq = irq_res->start;
+ irq_flags = irq_res->flags;
+ }
/*
* Now that that's out of the way, wire up the port..
*/
- host = ata_host_alloc(&pdev->dev, 1);
+ host = ata_host_alloc(dev, 1);
if (!host)
return -ENOMEM;
ap = host->ports[0];
ap->ops = &pata_platform_port_ops;
- ap->pio_mask = pio_mask;
+ ap->pio_mask = __pio_mask;
ap->flags |= ATA_FLAG_SLAVE_POSS;
/*
@@ -209,25 +185,24 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
* Handle the MMIO case
*/
if (mmio) {
- ap->ioaddr.cmd_addr = devm_ioremap(&pdev->dev, io_res->start,
+ ap->ioaddr.cmd_addr = devm_ioremap(dev, io_res->start,
io_res->end - io_res->start + 1);
- ap->ioaddr.ctl_addr = devm_ioremap(&pdev->dev, ctl_res->start,
+ ap->ioaddr.ctl_addr = devm_ioremap(dev, ctl_res->start,
ctl_res->end - ctl_res->start + 1);
} else {
- ap->ioaddr.cmd_addr = devm_ioport_map(&pdev->dev, io_res->start,
+ ap->ioaddr.cmd_addr = devm_ioport_map(dev, io_res->start,
io_res->end - io_res->start + 1);
- ap->ioaddr.ctl_addr = devm_ioport_map(&pdev->dev, ctl_res->start,
+ ap->ioaddr.ctl_addr = devm_ioport_map(dev, ctl_res->start,
ctl_res->end - ctl_res->start + 1);
}
if (!ap->ioaddr.cmd_addr || !ap->ioaddr.ctl_addr) {
- dev_err(&pdev->dev, "failed to map IO/CTL base\n");
+ dev_err(dev, "failed to map IO/CTL base\n");
return -ENOMEM;
}
ap->ioaddr.altstatus_addr = ap->ioaddr.ctl_addr;
- pp_info = pdev->dev.platform_data;
- pata_platform_setup_port(&ap->ioaddr, pp_info);
+ pata_platform_setup_port(&ap->ioaddr, ioport_shift);
ata_port_desc(ap, "%s cmd 0x%llx ctl 0x%llx", mmio ? "mmio" : "ioport",
(unsigned long long)io_res->start,
@@ -235,26 +210,78 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
/* activate */
return ata_host_activate(host, irq, irq ? ata_interrupt : NULL,
- pp_info ? pp_info->irq_flags : 0,
- &pata_platform_sht);
+ irq_flags, &pata_platform_sht);
}
+EXPORT_SYMBOL_GPL(__pata_platform_probe);
/**
- * pata_platform_remove - unplug a platform interface
- * @pdev: platform device
+ * __pata_platform_remove - unplug a platform interface
+ * @dev: device
*
* A platform bus ATA device has been unplugged. Perform the needed
* cleanup. Also called on module unload for any active devices.
*/
-static int __devexit pata_platform_remove(struct platform_device *pdev)
+int __devexit __pata_platform_remove(struct device *dev)
{
- struct device *dev = &pdev->dev;
struct ata_host *host = dev_get_drvdata(dev);
ata_host_detach(host);
return 0;
}
+EXPORT_SYMBOL_GPL(__pata_platform_remove);
+
+static int __devinit pata_platform_probe(struct platform_device *pdev)
+{
+ struct resource *io_res;
+ struct resource *ctl_res;
+ struct resource *irq_res;
+ struct pata_platform_info *pp_info = pdev->dev.platform_data;
+
+ /*
+ * Simple resource validation ..
+ */
+ if ((pdev->num_resources != 3) && (pdev->num_resources != 2)) {
+ dev_err(&pdev->dev, "invalid number of resources\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Get the I/O base first
+ */
+ io_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
+ if (io_res == NULL) {
+ io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (unlikely(io_res == NULL))
+ return -EINVAL;
+ }
+
+ /*
+ * Then the CTL base
+ */
+ ctl_res = platform_get_resource(pdev, IORESOURCE_IO, 1);
+ if (ctl_res == NULL) {
+ ctl_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (unlikely(ctl_res == NULL))
+ return -EINVAL;
+ }
+
+ /*
+ * And the IRQ
+ */
+ irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (irq_res)
+ irq_res->flags = pp_info ? pp_info->irq_flags : 0;
+
+ return __pata_platform_probe(&pdev->dev, io_res, ctl_res, irq_res,
+ pp_info ? pp_info->ioport_shift : 0,
+ pio_mask);
+}
+
+static int __devexit pata_platform_remove(struct platform_device *pdev)
+{
+ return __pata_platform_remove(&pdev->dev);
+}
static struct platform_driver pata_platform_driver = {
.probe = pata_platform_probe,
diff --git a/include/linux/pata_platform.h b/include/linux/pata_platform.h
index 5799e8d..6a7a92d 100644
--- a/include/linux/pata_platform.h
+++ b/include/linux/pata_platform.h
@@ -15,4 +15,13 @@ struct pata_platform_info {
unsigned int irq_flags;
};
+extern int __devinit __pata_platform_probe(struct device *dev,
+ struct resource *io_res,
+ struct resource *ctl_res,
+ struct resource *irq_res,
+ unsigned int ioport_shift,
+ int __pio_mask);
+
+extern int __devexit __pata_platform_remove(struct device *dev);
+
#endif /* __LINUX_PATA_PLATFORM_H */
--
1.5.2.2
^ permalink raw reply related
* [PATCH v2 0/4] OF-platform PATA driver
From: Anton Vorontsov @ 2007-12-04 17:04 UTC (permalink / raw)
To: linuxppc-dev, linux-ide
Cc: Jeff Garzik, Arnd Bergmann, Paul Mundt, Olof Johansson
Hi all,
Here is the second version of the OF-platform PATA driver and
related patches.
Arnd, the first patch has been changed, so technically it lost your
Acked-by.
- - -
Changes since v1:
- __pata_platform_probe now accepts pio_mask argument;
- pata-platform compatible property renamed to ata-generic;
- pata_of_platform understands pio-mode property. It's used to pass
pio_mask to the __pata_platform_probe. That is, in ata-generic
context pio-mode means "pio mode the bus already configured for";
- New optional patch that renames pata_platform_info's
ioport_shift to reg_shift.
Changes since RFC:
- nuked drivers/ata/pata_platform.h;
- powerpc bits: proper localbus node added.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH v2] Fix hardware IRQ time accounting problem.
From: Johannes Berg @ 2007-12-04 16:44 UTC (permalink / raw)
To: Tony Breeds
Cc: LinuxPPC-dev, Frederik Himpe, Paul Mackerras, Linux Kernel ML,
linux-usb-devel
In-Reply-To: <20071204055144.GR24243@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 2594 bytes --]
On Tue, 2007-12-04 at 16:51 +1100, Tony Breeds wrote:
> The commit fa13a5a1f25f671d084d8884be96fc48d9b68275 (sched: restore
> deterministic CPU accounting on powerpc), unconditionally calls
> update_process_tick() in system context. In the deterministic accounting case
> this is the correct thing to do. However, in the non-deterministic accounting
> case we need to not do this, and results in the time accounted as hardware irq
> time being artificially elevated.
Cool, I wouldn't have stood a chance of tracking this down :) Thanks,
I'll apply it to my testing tree later today.
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
> The problem was seen and reported by Johannes Berg and Frederik Himpe.
> Paul, I think this is good for 2.6.24.
>
> Changes since v1:
> - I noticed that the #define was explictly using "current" rather than
> the task passed in. Using tsk is the right thing to do.
> - The whiteapce changes dirty-up the patch and are un-needed with the
> change above.
>
> arch/powerpc/kernel/process.c | 2 +-
> include/asm-powerpc/time.h | 8 ++------
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 41e13f4..b9d8837 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -350,7 +350,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
> local_irq_save(flags);
>
> account_system_vtime(current);
> - account_process_tick(current, 0);
> + account_process_vtime(current);
> calculate_steal_time();
>
> last = _switch(old_thread, new_thread);
> diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h
> index 780f826..a7281e0 100644
> --- a/include/asm-powerpc/time.h
> +++ b/include/asm-powerpc/time.h
> @@ -237,18 +237,14 @@ struct cpu_usage {
>
> DECLARE_PER_CPU(struct cpu_usage, cpu_usage_array);
>
> -#ifdef CONFIG_VIRT_CPU_ACCOUNTING
> -extern void account_process_vtime(struct task_struct *tsk);
> -#else
> -#define account_process_vtime(tsk) do { } while (0)
> -#endif
> -
> #if defined(CONFIG_VIRT_CPU_ACCOUNTING)
> extern void calculate_steal_time(void);
> extern void snapshot_timebases(void);
> +#define account_process_vtime(tsk) account_process_tick(tsk, 0);
> #else
> #define calculate_steal_time() do { } while (0)
> #define snapshot_timebases() do { } while (0)
> +#define account_process_vtime(tsk) do { } while (0)
> #endif
>
> extern void secondary_cpu_time_init(void);
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [FDT][PATCH] Print out the total size as part of ftdump
From: Kumar Gala @ 2007-12-04 16:33 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
ftdump.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/ftdump.c b/ftdump.c
index 577c2cf..53343d7 100644
--- a/ftdump.c
+++ b/ftdump.c
@@ -87,6 +87,7 @@ static void dump_blob(void *blob)
char *p_struct = blob + be32_to_cpu(bph->off_dt_struct);
char *p_strings = blob + be32_to_cpu(bph->off_dt_strings);
uint32_t version = be32_to_cpu(bph->version);
+ uint32_t totalsize = be32_to_cpu(bph->totalsize);
uint32_t tag;
char *p;
char *s, *t;
@@ -98,6 +99,7 @@ static void dump_blob(void *blob)
shift = 4;
printf("// Version 0x%x tree\n", version);
+ printf("// Totalsize 0x%x(%d)\n", totalsize, totalsize);
for (i = 0; ; i++) {
addr = be64_to_cpu(p_rsvmap[i].address);
size = be64_to_cpu(p_rsvmap[i].size);
--
1.5.3.4
^ permalink raw reply related
* [FDT][PATCH] Fix padding options
From: Kumar Gala @ 2007-12-04 16:27 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
commit 22e787ca2b1e49a9a0f3c43262564ab1038c5c3c broke the padding
support. We were updating the fdt header after writing it.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
flattree.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/flattree.c b/flattree.c
index c860b63..eb9c82c 100644
--- a/flattree.c
+++ b/flattree.c
@@ -399,6 +399,12 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
if (padsize > 0)
padlen = padsize;
+ if (padlen > 0) {
+ int tsize = be32_to_cpu(fdt.totalsize);
+ tsize += padlen;
+ fdt.totalsize = cpu_to_be32(tsize);
+ }
+
/*
* Assemble the blob: start with the header, add with alignment
* the reserve buffer, add the reserve map terminating zeroes,
@@ -414,12 +420,8 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
/*
* If the user asked for more space than is used, pad out the blob.
*/
- if (padlen > 0) {
- int tsize = be32_to_cpu(fdt.totalsize);
- tsize += padlen;
+ if (padlen > 0)
blob = data_append_zeroes(blob, padlen);
- fdt.totalsize = cpu_to_be32(tsize);
- }
fwrite(blob.val, blob.len, 1, f);
--
1.5.3.4
^ permalink raw reply related
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Scott Wood @ 2007-12-04 16:08 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <4755731D.4050106@anagramm.de>
Clemens Koller wrote:
> Scott Wood schrieb:
> >> I would prefer to not tell the driver for 'foo' that it should attach to
> >> 0-0068
> >> because it should attach to the first i2c bus (0) it finds per default.
> >
> > Absolutely wrong.
>
> Hmm... Why?
It's error prone.
> > What if foo is on bus 1?
>
> Then I would need to tell the driver 'foo' that it should attach
> to 1-0068.
So we're back to the situation where drivers that aren't explicitly told
where to look are making assumptions that are possibly incorrect. You
should be able to enable drivers without harm, even if the hardware
isn't there.
> Propably you should see the bigger picture here:
Pot, meet kettle. :-)
> We just need to tell what we have, if it's not some default...
> statically (kconfig) or dynamically (of/dt) to get it right
> because we cannot probe for sure what we have (in contrast to PCI).
>
> I just don't want to be pushed into configuring things twice or on
> two different places because that's error prone.
The new system is far less error prone than the old system. You seem to
be suggesting a third system, with a radically different kconfig format
and no multiplatform support (again, this was one of your complaints in
your original e-mail -- why do you ignore it now?). Please show us the
code, or at least some description of how you would change kconfig to
get it up to the task, and how you would handle multiplatform kernels.
> >> Then I would need to tell 'bar' to attach to 1-0068. Where is the
> problem?
> >
> > OK, now say there's another foo on bus 2, and a pair of bars on buses
> 3 and
> > 4?
>
> Okay, let's play that game:
> foo -> connect an instance to 0-0068 and 2-0068
> bar -> connect an instance to 1-0068 and and 3-0068 and 4-0068
That doesn't resemble kconfig in the least -- and even if you transform
it into some sort of runtime-parsable textual list, what do those bus
numbers mean, anyway? How do you associate those with various i2c
buses, potentially coming from different i2c drivers? How do you
specify IRQs? How do you specify device variants among those the driver
supports? By the time you fix all of that, you'll basically have the
device tree.
The device tree provides a hierarchy that is well suited to handling
this sort of problem, and it also logically separates what the kernel
supports from what the hardware has (which is *necessary* for
multiplatform support).
> >> The 0068 is already redundant in the case of these RTCs because they
> are
> >> fixed.
> >
> > How do you know I'm even talking about RTCs?
>
> Well, the subject is about RTCs.
Not really, it's about a change in the i2c subsystem (I noticed you
didn't include the i2c list or linuxppc-dev... you'd get a larger
audience of the people that actually made the change that way). That it
happens to be an RTC chip you're using on the i2c bus is an
inconsequential detail.
> >> linux-2.6/Documentation/powerpc$ grep "rtc" *
> >> only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant,
> >> btw.).
> >> which could give a clue what's going on here.
> >> linux-2.6/Documentation/powerpc$ grep "fsl_soc" *
> >> - nothing -
> >
> > Uh, did you try grepping for "i2c"?
>
> No, I've just read the whole file from time to time.
OK, it seems the description of i2c devices didn't make it into that
file. I'm not sure why.
> That was discussed already in detail in several threads and there
> were already decisions made that the DT went into the kernel - no problem
> with that.
> I just don't see that it 'really does help' in it's current state if
> things are broken in a way they are hard to fix for non DT-familiar
> developers, almost impossible to fix for users which just need to
> compile their own kernel to achieve their project goal.
I agree there's been excessive roughness in the transition -- but in
this case, it's largely due to the i2c subsystem change, whereby a
driver can't be new-style and old-style at the same time. Thus, once
the driver is converted, all platforms have to register the device. On
powerpc, we happen to do it using the device tree (though you could do
it with board-specific platform code the way other arches do if you
really wanted).
> Well... let's take it easy. I'll dig into the pcf8563 code now.
BTW, there were patches posted recently by Jon Smirl to convert that
driver to new-style, and to change the i2c subsystem to have the OF
matches in the driver itself.
-Scott
^ permalink raw reply
* Re: Merge dtc
From: Kumar Gala @ 2007-12-04 16:04 UTC (permalink / raw)
To: Jon Loeliger, David Gibson
Cc: linuxppc-dev, Paul Mackerras, David Woodhouse, Paul
In-Reply-To: <20071204092611.79e08953@zod.rchland.ibm.com>
On Dec 4, 2007, at 9:26 AM, Josh Boyer wrote:
> On Tue, 04 Dec 2007 07:25:57 -0600
> Jon Loeliger <jdl@jdl.com> wrote:
>
>> So, like, the other day David Woodhouse mumbled:
>>>
>>> I think this is a bad idea -- it's hardly a difficult for those
>>> people
>>> who _do_ need dts to obtain it separately.
>>>
>>> We shouldn't be merging _more_ stuff in.
>>
>> Thanks for chiming in here, David W. As far as I can tell
>> so far, the only two people who have voiced an opinion on
>> this issue are Dave G, submitting patches, and me disagreeing
>> with the approach. :-)
>>
>> Anyone else?
>
> I don't see an overwhelmingly great reason to merge it. It might help
> test people who do automated rebuilds, etc and aren't used to dealing
> with powerpc and it's requirements. Outside of that, I see it as
> dual-maintenance.
>
> But I'm not doing the maintenance, and it doesn't effect me too much.
> I only ask that a decision is made and executed on soon so we can move
> on.
I'm also in disagreement of duplicating dtc in the kernel.
However, if we are going to do this we should make the path expansion
for labels work before we do it.
- k
^ permalink raw reply
* [PATCH] lparcfg: remove useless buffer allocation
From: Nathan Lynch @ 2007-12-04 16:03 UTC (permalink / raw)
To: linuxppc-dev
The 'data' member of proc_ppc64_lparcfg is unused, but the lparcfg
module's init routine allocates 4K for it.
Remove the code which allocates and frees this buffer.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
arch/powerpc/kernel/lparcfg.c | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
Tested with "cat /proc/ppc64/lparcfg" on Power5.
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index ff781b2..dcb89a8 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -41,7 +41,6 @@
/* #define LPARCFG_DEBUG */
static struct proc_dir_entry *proc_ppc64_lparcfg;
-#define LPARCFG_BUFF_SIZE 4096
/*
* Track sum of all purrs across all processors. This is used to further
@@ -595,13 +594,6 @@ int __init lparcfg_init(void)
ent = create_proc_entry("ppc64/lparcfg", mode, NULL);
if (ent) {
ent->proc_fops = &lparcfg_fops;
- ent->data = kmalloc(LPARCFG_BUFF_SIZE, GFP_KERNEL);
- if (!ent->data) {
- printk(KERN_ERR
- "Failed to allocate buffer for lparcfg\n");
- remove_proc_entry("lparcfg", ent->parent);
- return -ENOMEM;
- }
} else {
printk(KERN_ERR "Failed to create ppc64/lparcfg\n");
return -EIO;
@@ -613,10 +605,8 @@ int __init lparcfg_init(void)
void __exit lparcfg_cleanup(void)
{
- if (proc_ppc64_lparcfg) {
- kfree(proc_ppc64_lparcfg->data);
+ if (proc_ppc64_lparcfg)
remove_proc_entry("lparcfg", proc_ppc64_lparcfg->parent);
- }
}
module_init(lparcfg_init);
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-12-04 15:32 UTC (permalink / raw)
To: Scott Wood; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <20071204130841.GA5765@loki.buserror.net>
Hi, Scott!
Scott Wood schrieb:
>>> How would you tell the
>>> kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c
>>> bus
>>> 0, and a "bar" chip at address 0x68 on i2c bus 1?
>>
>> I would prefer to not tell the driver for 'foo' that it should attach to
>> 0-0068
>> because it should attach to the first i2c bus (0) it finds per default.
>
> Absolutely wrong.
Hmm... Why?
> What if foo is on bus 1?
Then I would need to tell the driver 'foo' that it should attach
to 1-0068. Sorry, I really don't understand your problem here.
If we have 'foo' on both busses, I need of course tell it
to attach to 0-0068 as well as 1-0068.
Propably you should see the bigger picture here:
We just need to tell what we have, if it's not some default...
statically (kconfig) or dynamically (of/dt) to get it right
because we cannot probe for sure what we have (in contrast to PCI).
I just don't want to be pushed into configuring things twice or on
two different places because that's error prone.
>> Then I would need to tell 'bar' to attach to 1-0068. Where is the problem?
>
> OK, now say there's another foo on bus 2, and a pair of bars on buses 3 and
> 4?
Okay, let's play that game:
foo -> connect an instance to 0-0068 and 2-0068
bar -> connect an instance to 1-0068 and and 3-0068 and 4-0068
If i.e. bar is a 8-page eeprom which hw-configurable addresses nailed
down to 0x50 and 0x58 to have a contigous eeprom area from 0x50 to 0x5f
it can also look like:
bar -> connect an instance to 1-0050 and 1-0058
I still don't see a conflict here.
You cannot connect more than one device to an address, that would
violate the I2C Spec. If you have different devices with the same
address, you have to nail down which ones belong together.
>> The 0068 is already redundant in the case of these RTCs because they are
>> fixed.
>
> How do you know I'm even talking about RTCs?
Well, the subject is about RTCs.
But still the same applys for other i2c devices.
> Those chips at 0x68 could be
> anything. There are many chips that don't have a single fixed address.
Sure. Just to make sure
>> There is already an example in the kernel for a very similar configuration
>> issue: see CONFIG_RTC_HCTOSYS_DEVICE.
>
> That's not remotely the same. That's telling a kernel init procedure what
> kernel device to use, not describing the layout of hardware.
I was trying to tell you that the structure to embed above information
is already there.
>>> The structure for this already present in kconfig,
>
> It is not.
Okay, our point of view is different here.
> We really should try to get the table populated with names for all of the
> new-style drivers in the kernel, though.
Yes. That's what's really necessary to put usability back in.
>> linux-2.6/Documentation/powerpc$ grep "rtc" *
>> only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant,
>> btw.).
>> which could give a clue what's going on here.
>> linux-2.6/Documentation/powerpc$ grep "fsl_soc" *
>> - nothing -
>
> Uh, did you try grepping for "i2c"?
No, I've just read the whole file from time to time.
>> The configuration process is away from KISS - I would simply
>> state: it's broken - or - it's a regression from 2.6.22.
>
> The transition could have been done more smoothly if the i2c driver model
> allowed a driver to be both new-style and old-style at the same time
> (subject to a config option to shut off old-style if it's screwing things
> up), I'll agree with that much.
> But please, try to understand that the
> device tree really does help.
That was discussed already in detail in several threads and there
were already decisions made that the DT went into the kernel - no problem
with that.
I just don't see that it 'really does help' in it's current state if
things are broken in a way they are hard to fix for non DT-familiar
developers, almost impossible to fix for users which just need to
compile their own kernel to achieve their project goal.
Well... let's take it easy. I'll dig into the pcf8563 code now.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: Merge dtc
From: Josh Boyer @ 2007-12-04 15:26 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Paul, David Woodhouse, Mackerras, David Gibson
In-Reply-To: <E1IzXmf-0005RJ-27@jdl.com>
On Tue, 04 Dec 2007 07:25:57 -0600
Jon Loeliger <jdl@jdl.com> wrote:
> So, like, the other day David Woodhouse mumbled:
> >
> > I think this is a bad idea -- it's hardly a difficult for those people
> > who _do_ need dts to obtain it separately.
> >
> > We shouldn't be merging _more_ stuff in.
>
> Thanks for chiming in here, David W. As far as I can tell
> so far, the only two people who have voiced an opinion on
> this issue are Dave G, submitting patches, and me disagreeing
> with the approach. :-)
>
> Anyone else?
I don't see an overwhelmingly great reason to merge it. It might help
test people who do automated rebuilds, etc and aren't used to dealing
with powerpc and it's requirements. Outside of that, I see it as
dual-maintenance.
But I'm not doing the maintenance, and it doesn't effect me too much.
I only ask that a decision is made and executed on soon so we can move
on.
josh
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Kamalesh Babulal @ 2007-12-04 14:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: Rafael J. Wysocki, linux-scsi, Matthew Wilcox, LKML,
Kyle McMartin, linuxppc-dev, Andrew Morton, Balbir Singh
In-Reply-To: <20071204122005.GA27286@elte.hu>
Ingo Molnar wrote:
> * Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>>> So 2.6.24-rc3 was OK and 2.6.24-rc3-git2 is not?
>> Yes, the 2.6.24-rc3 was Ok and this is seen from 2.6.24-rc3-git2/3/4.
>
> just to make sure: this is a real lockup and failed bootup (or device
> init), not just a message, right?
>
> Ingo
> --
Hi Ingo,
This softlockup is seen in the 2.6.24-rc4 either and looks like a message because
this is seen while running tbench and machine continues running other test's after
the softlockup messages and some times seen with the bootup, but the machines reaches the
login prompt and able to continue running tests.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
From: Grant Likely @ 2007-12-04 14:21 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, olof
In-Reply-To: <fa686aa40712040536h18bd60d3xf89af1f89f6a92ad@mail.gmail.com>
On 12/4/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 12/4/07, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > On Sat, 1 Dec 2007, Grant Likely wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > This patch makes the platform code use the new machine-specific initcall
> > > hooks. This has the advantage of not needing to explicitly test
> > > machine_is() at the top of every initcall function.
> >
> > You seem to have missed the PS3 *_initcall()s.
> > Probably because they test for firmware_has_feature(FW_FEATURE_PS3_LV1) instead
> > of machine_is(ps3).
>
> That's exactly why; I didn't know if 'machine_is(ps3)' was a suitable
> substitute so I left it alone.
On that topic; I left some pseries and iseries stuff alone also for
the same reason.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: dtc: Add may const qualifications
From: Jon Loeliger @ 2007-12-04 13:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071204032615.GK32577@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This adds 'const' qualifiers to many variables and functions. In
> particular it's now used for passing names to the tree accesor
> functions.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Typo fixed, rebased and applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
From: Geert Uytterhoeven @ 2007-12-04 13:43 UTC (permalink / raw)
To: Grant Likely, Geoff Levand; +Cc: olof, Linux/PPC Development
In-Reply-To: <fa686aa40712040536h18bd60d3xf89af1f89f6a92ad@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1414 bytes --]
On Tue, 4 Dec 2007, Grant Likely wrote:
> On 12/4/07, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > On Sat, 1 Dec 2007, Grant Likely wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > This patch makes the platform code use the new machine-specific initcall
> > > hooks. This has the advantage of not needing to explicitly test
> > > machine_is() at the top of every initcall function.
> >
> > You seem to have missed the PS3 *_initcall()s.
> > Probably because they test for firmware_has_feature(FW_FEATURE_PS3_LV1) instead
> > of machine_is(ps3).
>
> That's exactly why; I didn't know if 'machine_is(ps3)' was a suitable
> substitute so I left it alone.
I think it's OK. But...
Geoff: is there any specific reason why you used
firmware_has_feature(FW_FEATURE_PS3_LV1)?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
From: Grant Likely @ 2007-12-04 13:36 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, olof
In-Reply-To: <Pine.LNX.4.62.0712041320250.12181@pademelon.sonytel.be>
On 12/4/07, Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> On Sat, 1 Dec 2007, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > This patch makes the platform code use the new machine-specific initcall
> > hooks. This has the advantage of not needing to explicitly test
> > machine_is() at the top of every initcall function.
>
> You seem to have missed the PS3 *_initcall()s.
> Probably because they test for firmware_has_feature(FW_FEATURE_PS3_LV1) instead
> of machine_is(ps3).
That's exactly why; I didn't know if 'machine_is(ps3)' was a suitable
substitute so I left it alone.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] pasemi: Register i2c_board_info
From: David Woodhouse @ 2007-12-04 13:28 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071130032923.GB25580@lixom.net>
On Thu, 2007-11-29 at 21:29 -0600, Olof Johansson wrote:
> + continue;
> +
> + info.addr = *addr;
> +
> + i2c_register_board_info(PCI_FUNC(pdev->devfn),
> &info,
> + 1);
> + }
> + }
+ /* Ensure that buses up to 2 are reserved */
+ i2c_register_board_info(2, NULL, 0);
+
> + return 0;
> +}
> +device_initcall(pasemi_register_i2c_devices);
> +#endif
Otherwise when you make i2c-pasemi use i2c_add_numbered_adapter(), it
might fail to register the third bus -- because there were no devices
preregistered on it, so something else might have stolen that bus number
already.
You might want to add the patch to use i2c_add_numbered_adapter() to
your tree, btw.
--
dwmw2
^ permalink raw reply
* Re: dtc: Fix uninitialized use of structure_ok
From: Jon Loeliger @ 2007-12-04 13:28 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071204004943.GD32577@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> My rework of the tree checking code introduced a potentially nasty bug
> - it uses the structure_ok variable uninitialized. This patch fixes
> the problem. It's a fairly ugly bandaid approach, but the ugly will
> disappear once future patches have folded the semantic checks into the
> new framework.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks!
jdl
^ permalink raw reply
* Re: [PATCH][DTC] Add an option to pad the blob that is generated
From: Jon Loeliger @ 2007-12-04 13:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711281020240.5095@blarg.am.freescale.net>
So, like, the other day Kumar Gala mumbled:
> There are times when we need extra space in the blob and just want
> to have it added on w/o know the exact size to make it.
>
> The padding and min size options are mutually exclusive.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: Merge dtc
From: Jon Loeliger @ 2007-12-04 13:25 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <1196733544.13978.201.camel@pmac.infradead.org>
So, like, the other day David Woodhouse mumbled:
>
> I think this is a bad idea -- it's hardly a difficult for those people
> who _do_ need dts to obtain it separately.
>
> We shouldn't be merging _more_ stuff in.
Thanks for chiming in here, David W. As far as I can tell
so far, the only two people who have voiced an opinion on
this issue are Dave G, submitting patches, and me disagreeing
with the approach. :-)
Anyone else?
jdl
^ permalink raw reply
* Re: [PATCH 2/3] celleb: add supporting for native CBE
From: Arnd Bergmann @ 2007-12-04 13:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20071204.173824.-1350527485.kouish@swc.toshiba.co.jp>
On Tuesday 04 December 2007, Ishizaki Kou wrote:
> This patch adds supporting for native CBE on Celleb. =A0Many codes in
> platforms/cell/ are used when native CBE environment.
>=20
> Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp>
Ah, excellent to hear that this is now working!
I'd suggest doing the initialization in a different way, so that you don't
need to decide on so many attributes dynamically. The easiest way would
probably be to have two separate define_machine() calls in the celleb
definition, like
define_machine(celleb_beat) {
.probe =3D celleb_probe_beat,
.setup_arch =3D celleb_setup_arch_native,
.show_cpuinfo =3D celleb_show_cpuinfo,
.restart =3D beat_restart,
.power_off =3D beat_power_off,
.halt =3D beat_halt,
.get_rtc_time =3D beat_get_rtc_time,
.set_rtc_time =3D beat_set_rtc_time,
.calibrate_decr =3D generic_calibrate_decr,
.progress =3D celleb_progress,
.power_save =3D beat_power_save,
.nvram_size =3D beat_nvram_get_size,
.nvram_read =3D beat_nvram_read,
.nvram_write =3D beat_nvram_write,
.set_dabr =3D beat_set_xdabr,
.init_IRQ =3D beatic_init_IRQ,
.get_irq =3D beatic_get_irq,
.pci_probe_mode =3D celleb_pci_probe_mode,
.pci_setup_phb =3D celleb_setup_phb,
...
};
define_machine(celleb_native) {
.probe =3D celleb_probe_native,
.setup_arch =3D celleb_setup_arch_native,
.show_cpuinfo =3D celleb_show_cpuinfo,
.restart =3D rtas_restart,
.power_off =3D rtas_power_off,
.halt =3D rtas_halt,
.get_rtc_time =3D rtas_get_rtc_time,
.set_rtc_time =3D rtas_set_rtc_time,
.calibrate_decr =3D generic_calibrate_decr,
.progress =3D celleb_progress,
.init_IRQ =3D celleb_init_IRQ_native,
.get_irq =3D celleb_get_irq_native,
.pci_probe_mode =3D celleb_pci_probe_mode,
.pci_setup_phb =3D celleb_setup_phb,
...
};
=46or this, you can either have the two machine definitions in the
same celleb/setup.c, or split setup.c into machine specific files,
depending on how much ends up being shared in the end.
An interesting question still is how close the native celleb machine
definition is to the one from platforms/cell/setup.c. Maybe it's best
to have a common machine definition for these two in the end.
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: Jon Loeliger @ 2007-12-04 13:14 UTC (permalink / raw)
To: Jon Loeliger, linuxppc-dev@ozlabs.org
In-Reply-To: <20071204003354.GB32577@localhost.localdomain>
David Gibson wrote:
> On Mon, Dec 03, 2007 at 01:26:34PM -0600, Jon Loeliger wrote:
>> On Sun, 2007-12-02 at 19:50, David Gibson wrote:
>>
>>>> + clock-frequency = <7f28155>; /* 133.333333 MHz */
>>> You can use <d# 133333333> to avoid the ugly hex.
>> Better still, blaze a new trail, convert it to /dts-v1/ and
>> use clock-frequency = <133333333> straight up!
>
> Hrm.. probably best to wait for dtc to go into the kernel for that.
>
I disagree.
jdl
^ permalink raw reply
* Re: [PATCH] Add IPIC MSI interrupt support
From: Scott Wood @ 2007-12-04 13:13 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Gala Kumar, Li Tony
In-Reply-To: <1196769858.32524.8.camel@concordia>
On Tue, Dec 04, 2007 at 11:04:18PM +1100, Michael Ellerman wrote:
> On Tue, 2007-12-04 at 18:34 +0800, Li Tony wrote:
> > I am not very sure about spin_lock influence.
> > But maybe somebody will change the virq_to_hw implementation.
> > I will take virq_to_hw instead.
>
> I mean the time to take the function call should be pretty small
> compared to taking and releasing a spinlock - but if you have
> performance numbers to prove otherwise let me know :)
I don't think the IPIC is used on any SMP platforms at the moment, so
there's no spinlock overhead other than disabling interrupts...
That said, it's not worth reimplementing to avoid a function call.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] cell: fix undefined reference to mmio_nvram_init
From: Arnd Bergmann @ 2007-12-04 13:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20071204.173453.-1300514021.kouish@swc.toshiba.co.jp>
On Tuesday 04 December 2007, Ishizaki Kou wrote:
>=20
> +#ifdef CONFIG_MMIO_NVRAM
> =A0=A0=A0=A0=A0=A0=A0=A0mmio_nvram_init();
> +#endif
> =A0}
The patch is technically correct, but the preferred way of doing this is
to define a conditional inline function in the header, like:
#ifdef CONFIG_MMIO_NVRAM
extern int mmio_nvram_init(void);
#else
static inline int mmio_nvram_init(void)
{
return 0;
}
#endif
so that the caller does not need to know about it.
Arnd <><
^ permalink raw reply
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Scott Wood @ 2007-12-04 13:08 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <47553D31.4080306@anagramm.de>
On Tue, Dec 04, 2007 at 12:42:41PM +0100, Clemens Koller wrote:
> Scott Wood schrieb:
>> That's precisely what we do, via the device tree. It is not practical to
>> do it with kconfig.
>
> It's propably not practical to do it with kconfig right now,
It's not practical at all. It forces you to support one and only one target
per kernel image, and the basic structure of it is not nearly flexible
enough.
> but creating a separate configuration repository with strong relation to
> the kernel config is IMO the wrong way to do it.
It has a weak relation to the kernel config, not a strong one.
> > Again putting aside multiplatform kernels for the moment,
>> what would you do in kconfig to describe the addresses of multiple chips
>> without having a fixed-size list of possibilities?
>
> I don't see
?
> > How would you tell the
>> kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c
>> bus
>> 0, and a "bar" chip at address 0x68 on i2c bus 1?
>
> I would prefer to not tell the driver for 'foo' that it should attach to
> 0-0068
> because it should attach to the first i2c bus (0) it finds per default.
Absolutely wrong. What if foo is on bus 1?
> Then I would need to tell 'bar' to attach to 1-0068. Where is the problem?
OK, now say there's another foo on bus 2, and a pair of bars on buses 3 and
4?
> The 0068 is already redundant in the case of these RTCs because they are
> fixed.
How do you know I'm even talking about RTCs? Those chips at 0x68 could be
anything. There are many chips that don't have a single fixed address.
> There is already an example in the kernel for a very similar configuration
> issue: see CONFIG_RTC_HCTOSYS_DEVICE.
That's not remotely the same. That's telling a kernel init procedure what
kernel device to use, not describing the layout of hardware.
> The structure for this already present in kconfig,
It is not.
> and I don't see any road block not to be able to use it. If later on, we
> want to have OF to be able to reconfigure it in the form of a DT
> structure, we could still feed a tool like the dtc with the .config and
> generate one.
Please, feel free to make a patch that does this. You may find it to be a
bit more difficult than you thought. :-)
And again, there's the multiplatform issue.
> Just let me make the point clear, why I got so upset here: Having two
> different non-independent repositories make the configuration much more
> error-prone, especially if the second one (the DT) is partially redundant
> and not sufficiently documented.
The device tree is not a configuration repository, it is a description of
the hardware.
> Example:
> I need to use the PCF8563 on the MPC8540' I2C as well (*) - it
> was just working in 2.6.22. Now, somebody
>
> a) has to enable it in the kernel config
> b) then add it to the i2c_driver_device struct in fsl_soc.c
> c) then add it to the DTS.
>
> Step b and c are not difficult at all, but completely non-obvious
> and undocumented for non-developers. You actually have to dig in
> the code to find out that you need it and this s****.
Step b is something that only needs to be done once per chip, and step c is
something that only needs to be done once per board. Why is it unreasonable
for it to be done by a developer?
We really should try to get the table populated with names for all of the
new-style drivers in the kernel, though.
> linux-2.6/Documentation/powerpc$ grep "rtc" *
> only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant,
> btw.).
> which could give a clue what's going on here.
> linux-2.6/Documentation/powerpc$ grep "fsl_soc" *
> - nothing -
Uh, did you try grepping for "i2c"?
> The configuration process is away from KISS - I would simply
> state: it's broken - or - it's a regression from 2.6.22.
The transition could have been done more smoothly if the i2c driver model
allowed a driver to be both new-style and old-style at the same time
(subject to a config option to shut off old-style if it's screwing things
up), I'll agree with that much. But please, try to understand that the
device tree really does help.
-Scott
^ permalink raw reply
* Re: [PATCH] pci: Fix bus resource assignment on 32 bits with 64b resources
From: Geert Uytterhoeven @ 2007-12-04 12:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Greg Kroah-Hartman, linux-pci, linux-kernel, linuxppc-dev
In-Reply-To: <20071204060911.EA82BDDE19@ozlabs.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2306 bytes --]
On Tue, 4 Dec 2007, Benjamin Herrenschmidt wrote:
> The current pci_assign_unassigned_resources() code doesn't work properly
> on 32 bits platforms with 64 bits resources. The main reason is the use
> of unsigned long in various places instead of resource_size_t.
>
> This fixes it, along with some tricks to avoid casting to 64 bits on
> platforms that don't need it in every printk around.
>
> This is a pre-requisite for making powerpc use the generic code instead of
> its own half-useful implementation.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> drivers/pci/pci.h | 11 +++++++++++
> drivers/pci/setup-bus.c | 32 +++++++++++++++++---------------
> drivers/pci/setup-res.c | 5 ++---
> include/linux/pci.h | 4 ++--
> 4 files changed, 32 insertions(+), 20 deletions(-)
>
> Index: linux-work/drivers/pci/pci.h
> ===================================================================
> --- linux-work.orig/drivers/pci/pci.h 2007-12-04 17:00:43.000000000 +1100
> +++ linux-work/drivers/pci/pci.h 2007-12-04 17:02:11.000000000 +1100
> @@ -91,3 +91,14 @@ pci_match_one_device(const struct pci_de
> }
>
> struct pci_dev *pci_find_upstream_pcie_bridge(struct pci_dev *pdev);
> +
> +#ifdef CONFIG_RESOURCES_64BIT
> +#define RESOURCE_ORDER(order) (1ULL << (order))
> +#define RES_PR "%016llx"
> +#else
> +#define RESOURCE_ORDER(order) (1UL << (order))
> +#define RES_PR "%08lx"
> +#endif
> +
> +#define RANGE_PR RES_PR "-" RES_PR
Can we please have them in <linux/ioport.h>? They look very useful to me
elsewhere (other bus drivers, device drivers), too.
What about naming the printf format specifier macros more like in C99, e.g.
PRI*?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox