* Re: issues w/init
From: Kumar Gala @ 2009-04-17 13:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Scott Wood, Linuxppc-dev Development, Paul Mackerras
In-Reply-To: <1239964860.7443.65.camel@pasglop>
On Apr 17, 2009, at 5:41 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2009-04-17 at 20:05 +1000, Paul Mackerras wrote:
>> Benjamin Herrenschmidt writes:
>>
>>> I'm pretty sure they are broken already when running off a 64-bit
>>> kernel,
>>
>> Maybe not... for 64-bit kernels we have our definition of
>> elf_read_implies_exec in arch/powerpc/include/asm/elf.h, which IIRC
>> sets the read-implies-exec personality thing on old 32-bit binaries.
>
> Ok, so looking at that more closely, if that had worked, we would
> have had PROT_EXEC, and thus VM_EXEC added to the vma by mmap... which
> apparently didn't occur.
>
> I think what may be happening is that the binary he's running has the
> PT_GNU_STACK but his libc doesn't ... the kernel will set the
> personality flag based on the binary you are trying to run, not any
> library it uses...
>
> Kumar, can you try to instrument that a bit and tell us ? What the
> personality flag gets set to and whether mmap sets PROT_EXEC ?
I can and might have already done this, need to double check. But
what I was seeing from elf_map is that we don't get PROT_EXEC set for
this PHDR, but get VM_MAY_EXEC. I'm not clear on what VM_MAY_EXEC is
intended for.
- k
^ permalink raw reply
* Re: Proposed prom parse fix + moving.
From: Ilpo Järvinen @ 2009-04-17 13:02 UTC (permalink / raw)
To: Michal Simek; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <49E87D25.8090001@monstr.eu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1616 bytes --]
On Fri, 17 Apr 2009, Michal Simek wrote:
> Grant Likely wrote:
> > On Fri, Apr 17, 2009 at 12:08 AM, Michal Simek <monstr@monstr.eu> wrote:
> >> Hi All,
> >>
> >> I have got email from Ilpo about prom_parse file.
> >> I take this file from powerpc. Who did write prom_parse file and take care about?
> >
> > Posting to the linuxppc-dev list is sufficient to start. There are
> > several people who may be interested.
> >
> >> BTW: What about to move prom_parse file to any generic location as we discussed in past?
> >> Any volunteer?
> >
> > I'm kind of working on it. More specifically, I'm looking at
> > factoring out fdt stuff into common code (drivers/of/of_fdt.c). But I
> > haven't made a whole lot of progress yet.
> >
> >> -------- Original Message --------
> >> Subject: [RFC!] [PATCH] microblaze: fix bug in error handling
> >> Date: Thu, 16 Apr 2009 23:05:53 +0300 (EEST)
> >> From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> >> To: monstr@monstr.eu
> >> CC: microblaze-uclinux@itee.uq.edu.au
> >>
> >> While some version of the patches were on the lkml I read
> >> some part of the code briefly through but my feedback got
> >> stuck into postponed emails, so here's one correctness
> >> related issue I might have found (the rest were just
> >> cosmetic things).
> >>
> >> I'm not sure if the latter return needs the of_node_put or not
> >> but it seems more likely than not.
> >
> > Yes, it does. This change is applicable to
> > arch/powerpc/kernel/prom_parse.c too.
>
> ok.
> Ilpo: Can you create patch for both architectures?
Sure, but tomorrow as today is a deadline day :-).
--
i.
^ permalink raw reply
* Re: Proposed prom parse fix + moving.
From: Michal Simek @ 2009-04-17 12:59 UTC (permalink / raw)
To: Grant Likely; +Cc: ilpo.jarvinen, linuxppc-dev, Arnd Bergmann
In-Reply-To: <fa686aa40904162344y67115e50lf48c174501120b30@mail.gmail.com>
Grant Likely wrote:
> On Fri, Apr 17, 2009 at 12:08 AM, Michal Simek <monstr@monstr.eu> wrote:
>> Hi All,
>>
>> I have got email from Ilpo about prom_parse file.
>> I take this file from powerpc. Who did write prom_parse file and take care about?
>
> Posting to the linuxppc-dev list is sufficient to start. There are
> several people who may be interested.
>
>> BTW: What about to move prom_parse file to any generic location as we discussed in past?
>> Any volunteer?
>
> I'm kind of working on it. More specifically, I'm looking at
> factoring out fdt stuff into common code (drivers/of/of_fdt.c). But I
> haven't made a whole lot of progress yet.
>
>> -------- Original Message --------
>> Subject: [RFC!] [PATCH] microblaze: fix bug in error handling
>> Date: Thu, 16 Apr 2009 23:05:53 +0300 (EEST)
>> From: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
>> To: monstr@monstr.eu
>> CC: microblaze-uclinux@itee.uq.edu.au
>>
>> While some version of the patches were on the lkml I read
>> some part of the code briefly through but my feedback got
>> stuck into postponed emails, so here's one correctness
>> related issue I might have found (the rest were just
>> cosmetic things).
>>
>> I'm not sure if the latter return needs the of_node_put or not
>> but it seems more likely than not.
>
> Yes, it does. This change is applicable to
> arch/powerpc/kernel/prom_parse.c too.
ok.
Ilpo: Can you create patch for both architectures?
Thanks,
Michal
>
>> Not even compile tested.
>>
>> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
>> ---
>> arch/microblaze/kernel/prom_parse.c | 11 +++++++----
>> 1 files changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel/prom_parse.c
>> index ae0352e..d1174bc 100644
>> --- a/arch/microblaze/kernel/prom_parse.c
>> +++ b/arch/microblaze/kernel/prom_parse.c
>> @@ -927,20 +927,23 @@ int of_irq_map_one(struct device_node *device,
>> /* Get size of interrupt specifier */
>> tmp = of_get_property(p, "#interrupt-cells", NULL);
>> if (tmp == NULL) {
>> - of_node_put(p);
>> - return -EINVAL;
>> + res = -EINVAL;
>> + goto out;
>> }
>> intsize = *tmp;
>>
>> pr_debug(" intsize=%d intlen=%d\n", intsize, intlen);
>>
>> /* Check index */
>> - if ((index + 1) * intsize > intlen)
>> - return -EINVAL;
>> + if ((index + 1) * intsize > intlen) {
>> + res = -EINVAL;
>> + goto out;
>> + }
>>
>> /* Get new specifier and map it */
>> res = of_irq_map_raw(p, intspec + index * intsize, intsize,
>> addr, out_irq);
>> +out:
>> of_node_put(p);
>> return res;
>> }
>> --
>> 1.5.6.5
>>
>>
>> --
>> Michal Simek, Ing. (M.Eng)
>> w: www.monstr.eu p: +42-0-721842854
>>
>
>
>
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
^ permalink raw reply
* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Josh Boyer @ 2009-04-17 12:45 UTC (permalink / raw)
To: David Woodhouse
Cc: Artem Bityutskiy, linuxppc-dev, Stefan Roese, linux-mtd,
devicetree-discuss
In-Reply-To: <alpine.LFD.2.00.0904161936090.12608@baythorne.infradead.org>
On Thu, Apr 16, 2009 at 2:38 PM, David Woodhouse <dwmw2@infradead.org> wrot=
e:
> On Thu, 16 Apr 2009, Artem Bityutskiy wrote:
>
>> On Thu, 2009-04-16 at 07:46 -0600, Grant Likely wrote:
>>> Okay. =A0It will be good to get this one into -next for some testing
>>> exposure. =A0Unless he asks me to do otherwise, I'll leave this one to
>>> David to pick up.
>>
>> David usually picks up stuff just before or during merge window,
>> so if you want linux-next exposure, you need to have some extra
>> care.
>
> I don't necessarily do that on purpose; it just works out that way when I=
'm
> busy.
Are you ever _not_ busy? ;)
josh
^ permalink raw reply
* Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
From: Anton Vorontsov @ 2009-04-17 12:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide, Roderick Colenbrander, Bartlomiej Zolnierkiewicz,
linuxppc-dev
In-Reply-To: <1239954019.7443.47.camel@pasglop>
On Fri, Apr 17, 2009 at 09:40:19AM +0200, Benjamin Herrenschmidt wrote:
> On Thu, 2009-04-16 at 21:30 +0200, Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote:
> > > Hi,
> > >
> > > I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a
> > > Virtex-5 FPGA. The board also contains a ALI M1533 south bridge
> > > for IDE, USB and Audio. I did a lot of work to get the pci bus working
> > > on this board and it works correctly but the default init code
> > > of the alim15x3 driver doesn't work for me. The driver explicitly
> > > disabled some initialization code for powerpc after uncommenting this
> > > code it works properly. Benjamin Herrenschmidt and I think this
> > > !CONFIG_PPC check should be removed because the system behaves
> > > like a real 'x86' system (also the i8259 interrupt controller is used).
> >
> > Ben, I guess you are OK with the change and there are no longer other
> > platforms requiring CONFIG_PPC check below? [I don't see your ACK here]
>
> Yup. I don't see a case where the hack would be of any use, so I'm
> happy to remove us from the test. Whenever a 8259 is present we
> assign it the legacy interrupts 1...15 with a virtual==physical mapping
> so all those x86-ish things should run just fine.
But they don't. On MPC8610HPCD we have IDE interrupt directly
connected to the MPIC line (through PCI sideband interrupt), and
i8259 is _completely_ disabled in the bridge.
See this commit:
commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Tue Apr 29 22:57:38 2008 +0200
alim15x3: disable init_hwif_ali15x3 for PowerPC
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
If the patch applied, MPC8610HPCD will be broken.
We need at least some machine_is() check.
> > > Regards,
> > > Roderick Colenbrander
> > >
> > >
> > > From 1c40c2f1485ecd3bc5ad7a3af537cb94de0877c3 Mon Sep 17 00:00:00 2001
> > > From: Roderick Colenbrander <thunderbird2k@gmail.com>
> > > Date: Wed, 15 Apr 2009 10:45:17 +0200
> > > Subject: [PATCH] Use the 'x86' init_hwif code in the alim15x3 for
> > > x86-like PowerPC boards like Xilinx ML310/410/510.
> >
> > Roderick, please add your "Signed-off-by:" line
> > (per Documentation/SubmittingPatches).
> >
> > Thanks.
> >
> > > ---
> > > drivers/ide/alim15x3.c | 9 +++++----
> > > 1 files changed, 5 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c
> > > index 537da1c..9176c0f 100644
> > > --- a/drivers/ide/alim15x3.c
> > > +++ b/drivers/ide/alim15x3.c
> > > @@ -402,14 +402,15 @@ static u8 ali_cable_detect(ide_hwif_t *hwif)
> > > return cbl;
> > > }
> > >
> > > -#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC)
> > > +#if !defined(CONFIG_SPARC64)
> > > /**
> > > * init_hwif_ali15x3 - Initialize the ALI IDE x86 stuff
> > > * @hwif: interface to configure
> > > *
> > > * Obtain the IRQ tables for an ALi based IDE solution on the PC
> > > - * class platforms. This part of the code isn't applicable to the
> > > - * Sparc and PowerPC systems.
> > > + * class platforms. This part of the code isn't applicable to
> > > + * Sparc systems. It is usable on 'x86-like' PowerPC systems
> > > + * which use a Ali M15x3 south bridge like e.g. Xilinx ML310/410/510.
> > > */
> > >
> > > static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
> > > @@ -455,7 +456,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
> > > }
> > > #else
> > > #define init_hwif_ali15x3 NULL
> > > -#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */
> > > +#endif /* !defined(CONFIG_SPARC64) */
> > >
> > > /**
> > > * init_dma_ali15x3 - set up DMA on ALi15x3
> > > --
> > > 1.5.6.3
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 6/6] powerpc/fsl_soc: Isolate legacy fsl_spi support to mpc832x_rdb boards
From: Anton Vorontsov @ 2009-04-17 12:23 UTC (permalink / raw)
To: Peter Korsgaard
Cc: spi-devel-general, Andrew Morton, David Brownell, linux-kernel,
linuxppc-dev
In-Reply-To: <87bpr71p1o.fsf_-_@macbook.be.48ers.dk>
Hi Peter,
Sorry for the late response (and don't hesitate to ping me if I
don't answer, some things get lost in my inbox traffic, sorry).
On Wed, Apr 08, 2009 at 11:18:43AM +0200, Peter Korsgaard wrote:
> >>>>> "Anton" == Anton Vorontsov <avorontsov@ru.mvista.com> writes:
>
> Hi,
>
> Anton> The advantages of this:
> Anton> - Don't encourage legacy support;
> Anton> - Less external symbols, less code to compile-in for !MPC832x_RDB
> Anton> platforms.
>
> It's nice with your cleanups, but I wonder how to handle more
> complicated chip select handling than simply toggling a single gpio.
>
> I have a board (or 2 actually, but they are similar in this regard)
> with a mpc8347 using SPI to a number of addon boards. For signal
> integrity reasons the SPI signals are routed to a MUX, so the chip
> select logic has to set the MUX in addition to controlling the CS line
> of the device.
So that's just a bit complicated GPIO controller. I believe you
should describe it in the device tree and use it's muxed lines as
usual GPIOs.
Something ling
muxed_pio: gpio-controller@.. {
#gpio-cells = <2>;
compatible = "..,<board>-muxed-gpios";
reg = <...>;
gpios = <...>; <- specify pure BLK1, BLK2, OPT1, OPT2 GPIOs
gpio-controller;
};
And then,
> I've been using code like this since late 2007, but this patch
> ofcourse breaks it:
>
> static void thinx_spi_activate_cs(u8 cs, u8 polarity)
> {
> static u8 old_cs = 255;
>
> if (cs != old_cs) {
> /* mux setup (cs 2:1)*/
> gpio_set_value(gpio1 + GPIO_SPI_MUX_NOE, 1);
> gpio_set_value(gpio1 + GPIO_SPI_MUX_SEL0, cs&2);
> gpio_set_value(gpio1 + GPIO_SPI_MUX_SEL1, cs&4);
> gpio_set_value(gpio1 + GPIO_SPI_MUX_NOE, 0);
> old_cs = cs;
> }
>
> switch (cs) {
> case 0: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL1, polarity); break;
> case 1: gpio_set_value(gpio1 + GPIO_SPI_CS_BKL2, polarity); break;
> case 2: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT1, polarity); break;
> case 3: gpio_set_value(gpio1 + GPIO_SPI_CS_OPT2, polarity); break;
> }
> }
^^^ Put this logic into the "<board>-muxed-gpios" GPIO controller
driver.
Then spi node would look like this:
spi-controller@.. {
...
gpios = <&muxed_pio cs1 0 /* muxed CS_BLK1 */
&muxed_pio cs2 0 /* muxed CS_BLK2 */
&muxed_pio cs3 0 /* muxed CS_OPT1 */
&muxed_pio cs4 0>; /* muxed CS_OPT2 */
};
Hope this helps,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: issues w/init
From: Benjamin Herrenschmidt @ 2009-04-17 10:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <18920.21593.737132.732053@cargo.ozlabs.ibm.com>
On Fri, 2009-04-17 at 20:05 +1000, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > I'm pretty sure they are broken already when running off a 64-bit
> > kernel,
>
> Maybe not... for 64-bit kernels we have our definition of
> elf_read_implies_exec in arch/powerpc/include/asm/elf.h, which IIRC
> sets the read-implies-exec personality thing on old 32-bit binaries.
Ok, so looking at that more closely, if that had worked, we would
have had PROT_EXEC, and thus VM_EXEC added to the vma by mmap... which
apparently didn't occur.
I think what may be happening is that the binary he's running has the
PT_GNU_STACK but his libc doesn't ... the kernel will set the
personality flag based on the binary you are trying to run, not any
library it uses...
Kumar, can you try to instrument that a bit and tell us ? What the
personality flag gets set to and whether mmap sets PROT_EXEC ?
Cheers,
Ben.
^ permalink raw reply
* Re: issues w/init
From: Benjamin Herrenschmidt @ 2009-04-17 10:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <18920.21593.737132.732053@cargo.ozlabs.ibm.com>
On Fri, 2009-04-17 at 20:05 +1000, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > I'm pretty sure they are broken already when running off a 64-bit
> > kernel,
>
> Maybe not... for 64-bit kernels we have our definition of
> elf_read_implies_exec in arch/powerpc/include/asm/elf.h, which IIRC
> sets the read-implies-exec personality thing on old 32-bit binaries.
All or old ? ie. can we differenciate the broken from the "good" ones ?
In which case we can just fix that up here too.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] macintosh/mediabay should depend on BLOCK
From: Alexander Beregalov @ 2009-04-17 10:15 UTC (permalink / raw)
To: linuxppc-dev
Fix this build error
In file included from drivers/macintosh/mediabay.c:21:
include/linux/ide.h:605: error: field 'request_sense_rq' has incomplete type
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
---
drivers/macintosh/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 173cf55..3d90683 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -123,7 +123,7 @@ config PMAC_APM_EMU
config PMAC_MEDIABAY
bool "Support PowerBook hotswap media bay"
- depends on PPC_PMAC && PPC32
+ depends on PPC_PMAC && PPC32 && BLOCK
help
This option adds support for older PowerBook's hotswap media bay
that can contains batteries, floppy drives, or IDE devices. PCI
^ permalink raw reply related
* Re: issues w/init
From: Paul Mackerras @ 2009-04-17 10:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <1239953907.7443.45.camel@pasglop>
Benjamin Herrenschmidt writes:
> I'm pretty sure they are broken already when running off a 64-bit
> kernel,
Maybe not... for 64-bit kernels we have our definition of
elf_read_implies_exec in arch/powerpc/include/asm/elf.h, which IIRC
sets the read-implies-exec personality thing on old 32-bit binaries.
Paul.
^ permalink raw reply
* Re: pci32 code - early_*config*
From: Benjamin Herrenschmidt @ 2009-04-17 8:33 UTC (permalink / raw)
To: Roderick Colenbrander; +Cc: Linuxppc-dev Development
In-Reply-To: <c8485d470904170103g35e331b0g95d83613ed4bc1f4@mail.gmail.com>
On Fri, 2009-04-17 at 10:03 +0200, Roderick Colenbrander wrote:
>
> There are cases when it is really needed (or you would have to access
> the address and data bus by hand). In my case I'm using a Xilinx PLB
> soft-core and if certain options in the configuration header aren't
> set (which aren't set by default) the soft-core is basically disabled.
> Cases like this look like valid cases in which early config should be
> used.
I still wonder whether we could just setup the pci_controller data
structure and use "normal" PCI config access routines...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Artem Bityutskiy @ 2009-04-17 8:26 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, Stefan Roese, linux-mtd, devicetree-discuss
In-Reply-To: <alpine.LFD.2.00.0904161936090.12608@baythorne.infradead.org>
On Thu, 2009-04-16 at 19:38 +0100, David Woodhouse wrote:
> On Thu, 16 Apr 2009, Artem Bityutskiy wrote:
>
> > On Thu, 2009-04-16 at 07:46 -0600, Grant Likely wrote:
> >> On Thu, Apr 16, 2009 at 7:37 AM, Stefan Roese <sr@denx.de> wrote:
> >>> On Thursday 16 April 2009, Grant Likely wrote:
> >>>>> Signed-off-by: Stefan Roese <sr@denx.de>
> >>>>> Reviewd-by: Grant Likely <grant.likely@secretlab.ca>
> >>>>
> >>>> Yup, still looks good to me. What boards has this been tested on?
> >>>
> >>> I tested this version on PPC405EX Kilauea equipped only one "standard"
> >>> Spansion S29GL512 NOR chip. And a slightly modified version on an MPC8360
> >>> board (kmeter1) which is equipped with the Intel P30 part mentioned in the
> >>> bindings description. Slightly modified since this board support is not yet
> >>> pushed upstream and currently using v2.6.28 (physmap_of.c has received minor
> >>> modifications after 2.6.28 release).
> >>
> >> Okay. It will be good to get this one into -next for some testing
> >> exposure. Unless he asks me to do otherwise, I'll leave this one to
> >> David to pick up.
> >
> > David usually picks up stuff just before or during merge window,
> > so if you want linux-next exposure, you need to have some extra
> > care.
>
> I don't necessarily do that on purpose; it just works out that way when
> I'm busy.
Yeah, not that I try to blame you, but I think we need to expose stuff
to linux-next. And people who send patches are frustrated when their
stuff gets no attention for very long time.
I understand that MTD tree maintenance is a burden, and you are very
busy, and no one pays you for this job. Thanks for doing it!
I'm going to try to help you. I've just created a git tree where
I'll push patches I consider OK and I approve. Here it is:
git://git.infradead.org/users/dedekind/l2-mtd-2.6.git
My hope is that you would look at that tree from time to time
and pull it. At least you may be sure I looked at the patches and
did some validation. This should save your time and help MTD
users.
Thanks.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
^ permalink raw reply
* Re: pci32 code - early_*config*
From: Roderick Colenbrander @ 2009-04-17 8:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev Development
In-Reply-To: <1239953159.7443.33.camel@pasglop>
On Fri, Apr 17, 2009 at 9:25 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2009-04-15 at 01:17 -0500, Kumar Gala wrote:
>> Ben,
>>
>> I was looking at what I need to get some additional bits of PCI code
>> building w/your ppc64 booke patches. =A0One thing it looks like we need
>> is the early config cycle code. =A0The question I have is do we think we
>> still need the null_ops support? =A0Also do we think we every get called
>> with a NULL hose?
>>
>> This is fake_pci_bus() in arch/powerpc/kernel/pci_32.c
>
> Hrm.
>
> I'm not fan of the early config stuff, remind me why we need it ?
>
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
There are cases when it is really needed (or you would have to access
the address and data bus by hand). In my case I'm using a Xilinx PLB
soft-core and if certain options in the configuration header aren't
set (which aren't set by default) the soft-core is basically disabled.
Cases like this look like valid cases in which early config should be
used.
Roderick Colenbrander
^ permalink raw reply
* PPP over Synchronous HDLC in the Linux Kernel
From: Daniel Ng @ 2009-04-17 7:47 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hi,
Is there a way to integrate PPP over Synchronous HDLC using the
existing kernel code? We are currently using 2.6.27 on an 8272 ppc
board.
In the past, we have had this working on 2.6.14 by porting across Dan
Eble's PPC kernel patches, detailed below.
However, it seems these patches were never integrated into the kernel main line.
So, is it possible to implement PPP over Synchronous HDLC using the
current kernel code, without having to use these patches?
Cheers,
Daniel
Dan Eble's "Generic PPP for Generic HDLC" patches originally for a
2.4.21 kernel (PPC).
Patch details found at:
Kernel patches:
http://marc.theaimsgroup.com/?l=linux-net&m=105525978800615&w=2
http://marc.theaimsgroup.com/?l=linux-net&m=105526005200965&w=2
http://marc.theaimsgroup.com/?l=linux-net&m=105526034801396&w=2
PPP daemon patches:
http://marc.theaimsgroup.com/?l=linux-ppp&m=105526128502635&w=2
http://marc.theaimsgroup.com/?l=linux-ppp&m=105613926625787&w=2
^ permalink raw reply
* Re: Proposed prom parse fix + moving.
From: Benjamin Herrenschmidt @ 2009-04-17 7:43 UTC (permalink / raw)
To: monstr; +Cc: linuxppc-dev, Arnd Bergmann, ilpo.jarvinen
In-Reply-To: <49E81CED.1000704@monstr.eu>
On Fri, 2009-04-17 at 08:08 +0200, Michal Simek wrote:
> Hi All,
>
> I have got email from Ilpo about prom_parse file.
> I take this file from powerpc. Who did write prom_parse file and take care about?
I wrote it :-)
> BTW: What about to move prom_parse file to any generic location as we discussed in past?
> Any volunteer?
Well.. it relies on some bits and pieces that are rather powerpc
specific afaik such as our irq mapping scheme. I suppose we could split
those bits and move them to a separate file though.
Off hand the patch looks ok but I'll have to look more closely when
I get back from vacation.
Cheers,
Ben.
^ permalink raw reply
* Re: issues w/init
From: Benjamin Herrenschmidt @ 2009-04-17 7:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, Linuxppc-dev Development
In-Reply-To: <C17084D8-19F7-48D2-8E7E-2DE561108A90@kernel.crashing.org>
On Thu, 2009-04-16 at 14:27 -0500, Kumar Gala wrote:
> On Apr 16, 2009, at 2:25 PM, Scott Wood wrote:
>
> > Kumar Gala wrote:
> >> [root:~] cat /proc/1/maps
> >> 00100000-00103000 r-xp 00100000 00:00 0 [vdso]
> >> 0feab000-0ffbe000 r-xp 00000000 00:0d 7127086 /lib/libc-2.2.5.so
> >> 0ffbe000-0ffcb000 ---p 00113000 00:0d 7127086 /lib/libc-2.2.5.so
> >> 0ffcb000-0ffeb000 rw-p 00110000 00:0d 7127086 /lib/libc-2.2.5.so
> >
> > IIRC, this libc is old enough to execute out of non-exec memory in
> > some cases.
>
> Yeah, I'm going to that realization. The question is are we ok with
> breaking older versions of libc like this.
I'm pretty sure they are broken already when running off a 64-bit
kernel, but yeah, as I said, we may want a .config option to enable
support for that old junk which also disables support from per-page
execute permission.
Ben.
^ permalink raw reply
* Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
From: Benjamin Herrenschmidt @ 2009-04-17 7:40 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, Roderick Colenbrander, linuxppc-dev
In-Reply-To: <200904162130.01237.bzolnier@gmail.com>
On Thu, 2009-04-16 at 21:30 +0200, Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote:
> > Hi,
> >
> > I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a
> > Virtex-5 FPGA. The board also contains a ALI M1533 south bridge
> > for IDE, USB and Audio. I did a lot of work to get the pci bus working
> > on this board and it works correctly but the default init code
> > of the alim15x3 driver doesn't work for me. The driver explicitly
> > disabled some initialization code for powerpc after uncommenting this
> > code it works properly. Benjamin Herrenschmidt and I think this
> > !CONFIG_PPC check should be removed because the system behaves
> > like a real 'x86' system (also the i8259 interrupt controller is used).
>
> Ben, I guess you are OK with the change and there are no longer other
> platforms requiring CONFIG_PPC check below? [I don't see your ACK here]
Yup. I don't see a case where the hack would be of any use, so I'm
happy to remove us from the test. Whenever a 8259 is present we
assign it the legacy interrupts 1...15 with a virtual==physical mapping
so all those x86-ish things should run just fine.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Regards,
> > Roderick Colenbrander
> >
> >
> > From 1c40c2f1485ecd3bc5ad7a3af537cb94de0877c3 Mon Sep 17 00:00:00 2001
> > From: Roderick Colenbrander <thunderbird2k@gmail.com>
> > Date: Wed, 15 Apr 2009 10:45:17 +0200
> > Subject: [PATCH] Use the 'x86' init_hwif code in the alim15x3 for
> > x86-like PowerPC boards like Xilinx ML310/410/510.
>
> Roderick, please add your "Signed-off-by:" line
> (per Documentation/SubmittingPatches).
>
> Thanks.
>
> > ---
> > drivers/ide/alim15x3.c | 9 +++++----
> > 1 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c
> > index 537da1c..9176c0f 100644
> > --- a/drivers/ide/alim15x3.c
> > +++ b/drivers/ide/alim15x3.c
> > @@ -402,14 +402,15 @@ static u8 ali_cable_detect(ide_hwif_t *hwif)
> > return cbl;
> > }
> >
> > -#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC)
> > +#if !defined(CONFIG_SPARC64)
> > /**
> > * init_hwif_ali15x3 - Initialize the ALI IDE x86 stuff
> > * @hwif: interface to configure
> > *
> > * Obtain the IRQ tables for an ALi based IDE solution on the PC
> > - * class platforms. This part of the code isn't applicable to the
> > - * Sparc and PowerPC systems.
> > + * class platforms. This part of the code isn't applicable to
> > + * Sparc systems. It is usable on 'x86-like' PowerPC systems
> > + * which use a Ali M15x3 south bridge like e.g. Xilinx ML310/410/510.
> > */
> >
> > static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
> > @@ -455,7 +456,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
> > }
> > #else
> > #define init_hwif_ali15x3 NULL
> > -#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */
> > +#endif /* !defined(CONFIG_SPARC64) */
> >
> > /**
> > * init_dma_ali15x3 - set up DMA on ALi15x3
> > --
> > 1.5.6.3
^ permalink raw reply
* Re: issues w/init
From: Benjamin Herrenschmidt @ 2009-04-17 7:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development
In-Reply-To: <88F07543-B7F6-4F27-B5FB-4780AD069D7E@kernel.crashing.org>
On Thu, 2009-04-16 at 13:53 -0500, Kumar Gala wrote:
> A bit more debug info that might be helpful, I'm hitting this bad_area
> fault :
>
> if (!(vma->vm_flags & VM_EXEC) &&
> (cpu_has_feature(CPU_FTR_NOEXECUTE) ||
> !(vma->vm_flags & (VM_READ | VM_WRITE))))
> goto bad_area;
>
> bad_area 7 = 48024bf4 vm_flags:0810 0873
> SEGV 3 address:48024bf4 trap:400 error_code:0
Right, it's trying to execute off the data section (brobably just a blrl
instruction, that's what it used to do). You can see the VMA at 48022000
it's trying to execute from doesn't have the x bit set.
Toolchains were fixed, afaik, a while ago to properly mark the bit where
it does that executable, though the whole 32-bit ABI also got somewhat
overhauled to remove the need for that junk in the first place. I don't
remember the details off hand.
If we really want to support that old crap, then we probably need a
config option of some sort to force 32-bit to allow execution from
readable pages as I don't think we can identify such broken
binaries at runtime. Note that I'd be surprised if those binaries worked
under a 64-bit kernel, do you have a G5 you can try on ?
> [root:~] cat /proc/1/maps
> 00100000-00103000 r-xp 00100000 00:00 0 [vdso]
> 0feab000-0ffbe000 r-xp 00000000 00:0d 7127086 /lib/libc-2.2.5.so
> 0ffbe000-0ffcb000 ---p 00113000 00:0d 7127086 /lib/libc-2.2.5.so
> 0ffcb000-0ffeb000 rw-p 00110000 00:0d 7127086 /lib/libc-2.2.5.so
> 0ffeb000-0fff0000 rw-p 0ffeb000 00:00 0
> 10000000-10008000 r-xp 00000000 00:0d 9093222 /sbin/init
> 10017000-10018000 rw-p 00007000 00:0d 9093222 /sbin/init
> 10018000-1001c000 rwxp 10018000 00:00 0 [heap]
> 48000000-48013000 r-xp 00000000 00:0d 7127082 /lib/ld-2.2.5.so
> 48022000-48026000 rw-p 00012000 00:0d 7127082 /lib/ld-2.2.5.so
> bfd0e000-bfd23000 rwxp bffeb000 00:00 0 [stack]
^ permalink raw reply
* Re: issues w/init
From: Benjamin Herrenschmidt @ 2009-04-17 7:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development
In-Reply-To: <680ABFDC-A67F-48BB-B46C-564CB5373FEB@kernel.crashing.org>
On Thu, 2009-04-16 at 13:21 -0500, Kumar Gala wrote:
> Ben,
>
> The following patch is causing me issues w/init SEGV on boot. This is
> a pretty old version of init and I'm wondering what the commit you had
> related to old ABI breakage:
Can you test if the binary is trying to execute something that is
in a program section that isn't marked executable ? It could be
that it's build with a very old and broken toolchains.
(Note that when we finally add proper per-page exec permission support,
this will -also- break there even if we avoid that test below).
Maybe we can make a .config option for supporting obsolete crap that
tries to execute out of non executable sections ?
Cheers,
Ben.
> commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Tue Feb 10 16:02:37 2009 +0000
>
> powerpc/mm: Rework I$/D$ coherency (v3)
>
> This patch reworks the way we do I and D cache coherency on
> PowerPC.
>
>
> ---
> /*
> * Allow execution from readable areas if the MMU
> does not
> * provide separate controls over reading and
> executing.
> + *
> + * Note: That code used to not be enabled for 4xx/BookE.
> + * It is now as I/D cache coherency for these is done at
> + * set_pte_at() time and I see no reason why the test
> + * below wouldn't be valid on those processors. This -
> may-
> + * break programs compiled with a really old ABI though.
> */
>
> - k
^ permalink raw reply
* Re: powerpc-linux-gcc vs ppx_8xx-gcc and ppc_6xx-gcc
From: Wolfgang Denk @ 2009-04-17 7:31 UTC (permalink / raw)
To: Lixin Yao; +Cc: linuxppc-dev
In-Reply-To: <03D77CA4AC7F4D48A6AB5DA3F1001B3FB5BAC7@exchtxus2.HSTX.global.vpn>
Dear "Lixin Yao",
you should ask ELDK related questions on the ELDK mailing list, see
http://lists.denx.de/mailman/listinfo/eldk
In message <03D77CA4AC7F4D48A6AB5DA3F1001B3FB5BAC7@exchtxus2.HSTX.global.vpn> you wrote:
>
> I use ELDK 4.2 to work on platforms, one with MPC860 and the other with
> MPC8248.
>
> In installation, I see links:
> ppc_8xx-gcc -> ppc-linux-gcc
> ppc_6xx-gcc -> ppc-linux-gcc
> ppc-linux-gcc -> powerpc-linux-gcc
>
> I understand ppc_8xx-gcc needs to be used for MPC860 and ppc_6xx-gcc
> needs to be used for MPC8248. But both point to the same
> "powerpc-linux-gcc".
>
> What are the differences between powerpc-linux-gcc, ppx_8xx-gcc and
> ppc_6xx-gcc? What's the default target processorr of powerpc-linux-gcc?
You must always specify the wanted target architecture in the
CROSS_COMPILE environment variable. If you run ppc_6xx-gcc or
powerpc-linux-gcc (which is possible, but NOT recommended because
it's often difficult to detect misconfigurations like incorrect
CROSS_COMPILE settings) then the target architecture is taken from
the CROSS_COMPILE value.
It is recommended to set CROSS_COMPILE and then run
${CROSS_COMPILE}gcc because this allows easy switching between
different target architectures, i. e. you can write Makefiles that
work both natively and for cross development, and for any of the
supported target architectures without changes to the code.
See for example the Linux or U-Boot Makefiles which work this way.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Success covers a multitude of blunders." - George Bernard Shaw
^ permalink raw reply
* Re: [PATCH] windfarm: Convert to a new-style i2c drivers
From: Benjamin Herrenschmidt @ 2009-04-17 7:30 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20090416185615.2f7914ca@hyperion.delvare>
On Thu, 2009-04-16 at 18:56 +0200, Jean Delvare wrote:
> The legacy i2c binding model is going away soon, so convert the
> macintosh windfarm drivers to the new model or they will break.
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> ---
> Can someone please test this patch for me? I could only build-test it.
Thanks a lot for doing this. I'll be unable to test for a couple more
weeks as I'm on vacation and travelling though with a bit of luck,
Paulus will give it a go :-)
(Paul: windfarm_pm81 can be tested on the iMac G5 on my desk).
Cheers,
Ben.
> Remember that you need this patch applied:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=935298696f469c0e07c73be687bd055878074ce0
>
> Thanks.
>
> drivers/macintosh/windfarm_lm75_sensor.c | 131 +++++++++++++++------------
> drivers/macintosh/windfarm_max6690_sensor.c | 103 ++++++++++++---------
> drivers/macintosh/windfarm_smu_sat.c | 109 ++++++++++++----------
> 3 files changed, 198 insertions(+), 145 deletions(-)
>
> --- linux-2.6.30-rc2.orig/drivers/macintosh/windfarm_lm75_sensor.c 2009-04-16 11:15:00.000000000 +0200
> +++ linux-2.6.30-rc2/drivers/macintosh/windfarm_lm75_sensor.c 2009-04-16 11:23:17.000000000 +0200
> @@ -37,34 +37,22 @@
> struct wf_lm75_sensor {
> int ds1775 : 1;
> int inited : 1;
> - struct i2c_client i2c;
> + struct i2c_client *i2c;
> struct wf_sensor sens;
> };
> #define wf_to_lm75(c) container_of(c, struct wf_lm75_sensor, sens)
> -#define i2c_to_lm75(c) container_of(c, struct wf_lm75_sensor, i2c)
> -
> -static int wf_lm75_attach(struct i2c_adapter *adapter);
> -static int wf_lm75_detach(struct i2c_client *client);
> -
> -static struct i2c_driver wf_lm75_driver = {
> - .driver = {
> - .name = "wf_lm75",
> - },
> - .attach_adapter = wf_lm75_attach,
> - .detach_client = wf_lm75_detach,
> -};
>
> static int wf_lm75_get(struct wf_sensor *sr, s32 *value)
> {
> struct wf_lm75_sensor *lm = wf_to_lm75(sr);
> s32 data;
>
> - if (lm->i2c.adapter == NULL)
> + if (lm->i2c == NULL)
> return -ENODEV;
>
> /* Init chip if necessary */
> if (!lm->inited) {
> - u8 cfg_new, cfg = (u8)i2c_smbus_read_byte_data(&lm->i2c, 1);
> + u8 cfg_new, cfg = (u8)i2c_smbus_read_byte_data(lm->i2c, 1);
>
> DBG("wf_lm75: Initializing %s, cfg was: %02x\n",
> sr->name, cfg);
> @@ -73,7 +61,7 @@ static int wf_lm75_get(struct wf_sensor
> * the firmware for now
> */
> cfg_new = cfg & ~0x01;
> - i2c_smbus_write_byte_data(&lm->i2c, 1, cfg_new);
> + i2c_smbus_write_byte_data(lm->i2c, 1, cfg_new);
> lm->inited = 1;
>
> /* If we just powered it up, let's wait 200 ms */
> @@ -81,7 +69,7 @@ static int wf_lm75_get(struct wf_sensor
> }
>
> /* Read temperature register */
> - data = (s32)le16_to_cpu(i2c_smbus_read_word_data(&lm->i2c, 0));
> + data = (s32)le16_to_cpu(i2c_smbus_read_word_data(lm->i2c, 0));
> data <<= 8;
> *value = data;
>
> @@ -92,12 +80,6 @@ static void wf_lm75_release(struct wf_se
> {
> struct wf_lm75_sensor *lm = wf_to_lm75(sr);
>
> - /* check if client is registered and detach from i2c */
> - if (lm->i2c.adapter) {
> - i2c_detach_client(&lm->i2c);
> - lm->i2c.adapter = NULL;
> - }
> -
> kfree(lm);
> }
>
> @@ -107,59 +89,77 @@ static struct wf_sensor_ops wf_lm75_ops
> .owner = THIS_MODULE,
> };
>
> -static struct wf_lm75_sensor *wf_lm75_create(struct i2c_adapter *adapter,
> - u8 addr, int ds1775,
> - const char *loc)
> +static int wf_lm75_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> {
> struct wf_lm75_sensor *lm;
> int rc;
>
> - DBG("wf_lm75: creating %s device at address 0x%02x\n",
> - ds1775 ? "ds1775" : "lm75", addr);
> -
> lm = kzalloc(sizeof(struct wf_lm75_sensor), GFP_KERNEL);
> if (lm == NULL)
> - return NULL;
> + return -ENODEV;
> +
> + lm->inited = 0;
> + lm->ds1775 = id->driver_data;
> + lm->i2c = client;
> + lm->sens.name = client->dev.platform_data;
> + lm->sens.ops = &wf_lm75_ops;
> + i2c_set_clientdata(client, lm);
> +
> + rc = wf_register_sensor(&lm->sens);
> + if (rc) {
> + i2c_set_clientdata(client, NULL);
> + kfree(lm);
> + }
> +
> + return rc;
> +}
> +
> +static struct i2c_client *wf_lm75_create(struct i2c_adapter *adapter,
> + u8 addr, int ds1775,
> + const char *loc)
> +{
> + struct i2c_board_info info;
> + struct i2c_client *client;
> + char *name;
> +
> + DBG("wf_lm75: creating %s device at address 0x%02x\n",
> + ds1775 ? "ds1775" : "lm75", addr);
>
> /* Usual rant about sensor names not beeing very consistent in
> * the device-tree, oh well ...
> * Add more entries below as you deal with more setups
> */
> if (!strcmp(loc, "Hard drive") || !strcmp(loc, "DRIVE BAY"))
> - lm->sens.name = "hd-temp";
> + name = "hd-temp";
> else if (!strcmp(loc, "Incoming Air Temp"))
> - lm->sens.name = "incoming-air-temp";
> + name = "incoming-air-temp";
> else if (!strcmp(loc, "ODD Temp"))
> - lm->sens.name = "optical-drive-temp";
> + name = "optical-drive-temp";
> else if (!strcmp(loc, "HD Temp"))
> - lm->sens.name = "hard-drive-temp";
> + name = "hard-drive-temp";
> else
> goto fail;
>
> - lm->inited = 0;
> - lm->sens.ops = &wf_lm75_ops;
> - lm->ds1775 = ds1775;
> - lm->i2c.addr = (addr >> 1) & 0x7f;
> - lm->i2c.adapter = adapter;
> - lm->i2c.driver = &wf_lm75_driver;
> - strncpy(lm->i2c.name, lm->sens.name, I2C_NAME_SIZE-1);
> -
> - rc = i2c_attach_client(&lm->i2c);
> - if (rc) {
> - printk(KERN_ERR "windfarm: failed to attach %s %s to i2c,"
> - " err %d\n", ds1775 ? "ds1775" : "lm75",
> - lm->i2c.name, rc);
> - goto fail;
> - }
> -
> - if (wf_register_sensor(&lm->sens)) {
> - i2c_detach_client(&lm->i2c);
> + memset(&info, 0, sizeof(struct i2c_board_info));
> + info.addr = (addr >> 1) & 0x7f;
> + info.platform_data = name;
> + strlcpy(info.type, ds1775 ? "wf_ds1775" : "wf_lm75", I2C_NAME_SIZE);
> +
> + client = i2c_new_device(adapter, &info);
> + if (client == NULL) {
> + printk(KERN_ERR "windfarm: failed to attach %s %s to i2c\n",
> + ds1775 ? "ds1775" : "lm75", name);
> goto fail;
> }
>
> - return lm;
> + /*
> + * Let i2c-core delete that device on driver removal.
> + * This is safe because i2c-core holds the core_lock mutex for us.
> + */
> + list_add_tail(&client->detected, &client->driver->clients);
> + return client;
> fail:
> - kfree(lm);
> return NULL;
> }
>
> @@ -202,21 +202,38 @@ static int wf_lm75_attach(struct i2c_ada
> return 0;
> }
>
> -static int wf_lm75_detach(struct i2c_client *client)
> +static int wf_lm75_remove(struct i2c_client *client)
> {
> - struct wf_lm75_sensor *lm = i2c_to_lm75(client);
> + struct wf_lm75_sensor *lm = i2c_get_clientdata(client);
>
> DBG("wf_lm75: i2c detatch called for %s\n", lm->sens.name);
>
> /* Mark client detached */
> - lm->i2c.adapter = NULL;
> + lm->i2c = NULL;
>
> /* release sensor */
> wf_unregister_sensor(&lm->sens);
>
> + i2c_set_clientdata(client, NULL);
> return 0;
> }
>
> +static const struct i2c_device_id wf_lm75_id[] = {
> + { "wf_lm75", 0 },
> + { "wf_ds1775", 1 },
> + { }
> +};
> +
> +static struct i2c_driver wf_lm75_driver = {
> + .driver = {
> + .name = "wf_lm75",
> + },
> + .attach_adapter = wf_lm75_attach,
> + .probe = wf_lm75_probe,
> + .remove = wf_lm75_remove,
> + .id_table = wf_lm75_id,
> +};
> +
> static int __init wf_lm75_sensor_init(void)
> {
> /* Don't register on old machines that use therm_pm72 for now */
> --- linux-2.6.30-rc2.orig/drivers/macintosh/windfarm_max6690_sensor.c 2009-04-16 17:45:07.000000000 +0200
> +++ linux-2.6.30-rc2/drivers/macintosh/windfarm_max6690_sensor.c 2009-04-16 17:45:13.000000000 +0200
> @@ -26,34 +26,22 @@
> #define MAX6690_EXTERNAL_TEMP 1
>
> struct wf_6690_sensor {
> - struct i2c_client i2c;
> + struct i2c_client *i2c;
> struct wf_sensor sens;
> };
>
> #define wf_to_6690(x) container_of((x), struct wf_6690_sensor, sens)
> -#define i2c_to_6690(x) container_of((x), struct wf_6690_sensor, i2c)
> -
> -static int wf_max6690_attach(struct i2c_adapter *adapter);
> -static int wf_max6690_detach(struct i2c_client *client);
> -
> -static struct i2c_driver wf_max6690_driver = {
> - .driver = {
> - .name = "wf_max6690",
> - },
> - .attach_adapter = wf_max6690_attach,
> - .detach_client = wf_max6690_detach,
> -};
>
> static int wf_max6690_get(struct wf_sensor *sr, s32 *value)
> {
> struct wf_6690_sensor *max = wf_to_6690(sr);
> s32 data;
>
> - if (max->i2c.adapter == NULL)
> + if (max->i2c == NULL)
> return -ENODEV;
>
> /* chip gets initialized by firmware */
> - data = i2c_smbus_read_byte_data(&max->i2c, MAX6690_EXTERNAL_TEMP);
> + data = i2c_smbus_read_byte_data(max->i2c, MAX6690_EXTERNAL_TEMP);
> if (data < 0)
> return data;
> *value = data << 16;
> @@ -64,10 +52,6 @@ static void wf_max6690_release(struct wf
> {
> struct wf_6690_sensor *max = wf_to_6690(sr);
>
> - if (max->i2c.adapter) {
> - i2c_detach_client(&max->i2c);
> - max->i2c.adapter = NULL;
> - }
> kfree(max);
> }
>
> @@ -77,19 +61,40 @@ static struct wf_sensor_ops wf_max6690_o
> .owner = THIS_MODULE,
> };
>
> -static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr,
> - const char *loc)
> +static int wf_max6690_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> {
> struct wf_6690_sensor *max;
> - char *name;
> + int rc;
>
> max = kzalloc(sizeof(struct wf_6690_sensor), GFP_KERNEL);
> if (max == NULL) {
> - printk(KERN_ERR "windfarm: Couldn't create MAX6690 sensor %s: "
> - "no memory\n", loc);
> - return;
> + printk(KERN_ERR "windfarm: Couldn't create MAX6690 sensor: "
> + "no memory\n");
> + return -ENOMEM;
> + }
> +
> + max->i2c = client;
> + max->sens.name = client->dev.platform_data;
> + max->sens.ops = &wf_max6690_ops;
> + i2c_set_clientdata(client, max);
> +
> + rc = wf_register_sensor(&max->sens);
> + if (rc) {
> + i2c_set_clientdata(client, NULL);
> + kfree(max);
> }
>
> + return rc;
> +}
> +
> +static struct i2c_client *wf_max6690_create(struct i2c_adapter *adapter,
> + u8 addr, const char *loc)
> +{
> + struct i2c_board_info info;
> + struct i2c_client *client;
> + char *name;
> +
> if (!strcmp(loc, "BACKSIDE"))
> name = "backside-temp";
> else if (!strcmp(loc, "NB Ambient"))
> @@ -99,27 +104,26 @@ static void wf_max6690_create(struct i2c
> else
> goto fail;
>
> - max->sens.ops = &wf_max6690_ops;
> - max->sens.name = name;
> - max->i2c.addr = addr >> 1;
> - max->i2c.adapter = adapter;
> - max->i2c.driver = &wf_max6690_driver;
> - strncpy(max->i2c.name, name, I2C_NAME_SIZE-1);
> + memset(&info, 0, sizeof(struct i2c_board_info));
> + info.addr = addr >> 1;
> + info.platform_data = name;
> + strlcpy(info.type, "wf_max6690", I2C_NAME_SIZE);
>
> - if (i2c_attach_client(&max->i2c)) {
> + client = i2c_new_device(adapter, &info);
> + if (client == NULL) {
> printk(KERN_ERR "windfarm: failed to attach MAX6690 sensor\n");
> goto fail;
> }
>
> - if (wf_register_sensor(&max->sens)) {
> - i2c_detach_client(&max->i2c);
> - goto fail;
> - }
> -
> - return;
> + /*
> + * Let i2c-core delete that device on driver removal.
> + * This is safe because i2c-core holds the core_lock mutex for us.
> + */
> + list_add_tail(&client->detected, &client->driver->clients);
> + return client;
>
> fail:
> - kfree(max);
> + return NULL;
> }
>
> static int wf_max6690_attach(struct i2c_adapter *adapter)
> @@ -154,16 +158,31 @@ static int wf_max6690_attach(struct i2c_
> return 0;
> }
>
> -static int wf_max6690_detach(struct i2c_client *client)
> +static int wf_max6690_remove(struct i2c_client *client)
> {
> - struct wf_6690_sensor *max = i2c_to_6690(client);
> + struct wf_6690_sensor *max = i2c_get_clientdata(client);
>
> - max->i2c.adapter = NULL;
> + max->i2c = NULL;
> wf_unregister_sensor(&max->sens);
>
> return 0;
> }
>
> +static const struct i2c_device_id wf_max6690_id[] = {
> + { "wf_max6690", 0 },
> + { }
> +};
> +
> +static struct i2c_driver wf_max6690_driver = {
> + .driver = {
> + .name = "wf_max6690",
> + },
> + .attach_adapter = wf_max6690_attach,
> + .probe = wf_max6690_probe,
> + .remove = wf_max6690_remove,
> + .id_table = wf_max6690_id,
> +};
> +
> static int __init wf_max6690_sensor_init(void)
> {
> /* Don't register on old machines that use therm_pm72 for now */
> --- linux-2.6.30-rc2.orig/drivers/macintosh/windfarm_smu_sat.c 2009-04-16 17:45:06.000000000 +0200
> +++ linux-2.6.30-rc2/drivers/macintosh/windfarm_smu_sat.c 2009-04-16 18:13:07.000000000 +0200
> @@ -39,7 +39,7 @@ struct wf_sat {
> struct mutex mutex;
> unsigned long last_read; /* jiffies when cache last updated */
> u8 cache[16];
> - struct i2c_client i2c;
> + struct i2c_client *i2c;
> struct device_node *node;
> };
>
> @@ -54,18 +54,6 @@ struct wf_sat_sensor {
> };
>
> #define wf_to_sat(c) container_of(c, struct wf_sat_sensor, sens)
> -#define i2c_to_sat(c) container_of(c, struct wf_sat, i2c)
> -
> -static int wf_sat_attach(struct i2c_adapter *adapter);
> -static int wf_sat_detach(struct i2c_client *client);
> -
> -static struct i2c_driver wf_sat_driver = {
> - .driver = {
> - .name = "wf_smu_sat",
> - },
> - .attach_adapter = wf_sat_attach,
> - .detach_client = wf_sat_detach,
> -};
>
> struct smu_sdbp_header *smu_sat_get_sdb_partition(unsigned int sat_id, int id,
> unsigned int *size)
> @@ -81,13 +69,13 @@ struct smu_sdbp_header *smu_sat_get_sdb_
> if (sat_id > 1 || (sat = sats[sat_id]) == NULL)
> return NULL;
>
> - err = i2c_smbus_write_word_data(&sat->i2c, 8, id << 8);
> + err = i2c_smbus_write_word_data(sat->i2c, 8, id << 8);
> if (err) {
> printk(KERN_ERR "smu_sat_get_sdb_part wr error %d\n", err);
> return NULL;
> }
>
> - err = i2c_smbus_read_word_data(&sat->i2c, 9);
> + err = i2c_smbus_read_word_data(sat->i2c, 9);
> if (err < 0) {
> printk(KERN_ERR "smu_sat_get_sdb_part rd len error\n");
> return NULL;
> @@ -105,7 +93,7 @@ struct smu_sdbp_header *smu_sat_get_sdb_
> return NULL;
>
> for (i = 0; i < len; i += 4) {
> - err = i2c_smbus_read_i2c_block_data(&sat->i2c, 0xa, 4, data);
> + err = i2c_smbus_read_i2c_block_data(sat->i2c, 0xa, 4, data);
> if (err < 0) {
> printk(KERN_ERR "smu_sat_get_sdb_part rd err %d\n",
> err);
> @@ -138,7 +126,7 @@ static int wf_sat_read_cache(struct wf_s
> {
> int err;
>
> - err = i2c_smbus_read_i2c_block_data(&sat->i2c, 0x3f, 16, sat->cache);
> + err = i2c_smbus_read_i2c_block_data(sat->i2c, 0x3f, 16, sat->cache);
> if (err < 0)
> return err;
> sat->last_read = jiffies;
> @@ -161,7 +149,7 @@ static int wf_sat_get(struct wf_sensor *
> int i, err;
> s32 val;
>
> - if (sat->i2c.adapter == NULL)
> + if (sat->i2c == NULL)
> return -ENODEV;
>
> mutex_lock(&sat->mutex);
> @@ -193,10 +181,6 @@ static void wf_sat_release(struct wf_sen
> struct wf_sat *sat = sens->sat;
>
> if (atomic_dec_and_test(&sat->refcnt)) {
> - if (sat->i2c.adapter) {
> - i2c_detach_client(&sat->i2c);
> - sat->i2c.adapter = NULL;
> - }
> if (sat->nr >= 0)
> sats[sat->nr] = NULL;
> kfree(sat);
> @@ -212,38 +196,58 @@ static struct wf_sensor_ops wf_sat_ops =
>
> static void wf_sat_create(struct i2c_adapter *adapter, struct device_node *dev)
> {
> + struct i2c_board_info info;
> + struct i2c_client *client;
> + const u32 *reg;
> + u8 addr;
> +
> + reg = of_get_property(dev, "reg", NULL);
> + if (reg == NULL)
> + return;
> + addr = *reg;
> + DBG(KERN_DEBUG "wf_sat: creating sat at address %x\n", addr);
> +
> + memset(&info, 0, sizeof(struct i2c_board_info));
> + info.addr = (addr >> 1) & 0x7f;
> + info.platform_data = dev;
> + strlcpy(info.type, "wf_sat", I2C_NAME_SIZE);
> +
> + client = i2c_new_device(adapter, &info);
> + if (client == NULL) {
> + printk(KERN_ERR "windfarm: failed to attach smu-sat to i2c\n");
> + return;
> + }
> +
> + /*
> + * Let i2c-core delete that device on driver removal.
> + * This is safe because i2c-core holds the core_lock mutex for us.
> + */
> + list_add_tail(&client->detected, &client->driver->clients);
> +}
> +
> +static int wf_sat_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device_node *dev = client->dev.platform_data;
> struct wf_sat *sat;
> struct wf_sat_sensor *sens;
> const u32 *reg;
> const char *loc, *type;
> - u8 addr, chip, core;
> + u8 chip, core;
> struct device_node *child;
> int shift, cpu, index;
> char *name;
> int vsens[2], isens[2];
>
> - reg = of_get_property(dev, "reg", NULL);
> - if (reg == NULL)
> - return;
> - addr = *reg;
> - DBG(KERN_DEBUG "wf_sat: creating sat at address %x\n", addr);
> -
> sat = kzalloc(sizeof(struct wf_sat), GFP_KERNEL);
> if (sat == NULL)
> - return;
> + return -ENOMEM;
> sat->nr = -1;
> sat->node = of_node_get(dev);
> atomic_set(&sat->refcnt, 0);
> mutex_init(&sat->mutex);
> - sat->i2c.addr = (addr >> 1) & 0x7f;
> - sat->i2c.adapter = adapter;
> - sat->i2c.driver = &wf_sat_driver;
> - strncpy(sat->i2c.name, "smu-sat", I2C_NAME_SIZE-1);
> -
> - if (i2c_attach_client(&sat->i2c)) {
> - printk(KERN_ERR "windfarm: failed to attach smu-sat to i2c\n");
> - goto fail;
> - }
> + sat->i2c = client;
> + i2c_set_clientdata(client, sat);
>
> vsens[0] = vsens[1] = -1;
> isens[0] = isens[1] = -1;
> @@ -344,10 +348,7 @@ static void wf_sat_create(struct i2c_ada
> if (sat->nr >= 0)
> sats[sat->nr] = sat;
>
> - return;
> -
> - fail:
> - kfree(sat);
> + return 0;
> }
>
> static int wf_sat_attach(struct i2c_adapter *adapter)
> @@ -366,16 +367,32 @@ static int wf_sat_attach(struct i2c_adap
> return 0;
> }
>
> -static int wf_sat_detach(struct i2c_client *client)
> +static int wf_sat_remove(struct i2c_client *client)
> {
> - struct wf_sat *sat = i2c_to_sat(client);
> + struct wf_sat *sat = i2c_get_clientdata(client);
>
> /* XXX TODO */
>
> - sat->i2c.adapter = NULL;
> + sat->i2c = NULL;
> + i2c_set_clientdata(client, NULL);
> return 0;
> }
>
> +static const struct i2c_device_id wf_sat_id[] = {
> + { "wf_sat", 0 },
> + { }
> +};
> +
> +static struct i2c_driver wf_sat_driver = {
> + .driver = {
> + .name = "wf_smu_sat",
> + },
> + .attach_adapter = wf_sat_attach,
> + .probe = wf_sat_probe,
> + .remove = wf_sat_remove,
> + .id_table = wf_sat_id,
> +};
> +
> static int __init sat_sensors_init(void)
> {
> return i2c_add_driver(&wf_sat_driver);
>
>
^ permalink raw reply
* Re: Question about windfarm drivers
From: Benjamin Herrenschmidt @ 2009-04-17 7:28 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20090416105216.27c3f715@hyperion.delvare>
On Thu, 2009-04-16 at 10:52 +0200, Jean Delvare wrote:
> In wf_lm75_release(), i2c_detach_client() is called if and only if
> lm->i2c.adapter is set, which is not the case, and then the data
> structure, including the i2c client, is freed from memory. This means
> that the freed i2c client is still registered with i2c-core, this looks
> wrong.
>
> Am I missing something? Or is this clean-up path broken and nobody ever
> noticed?
Probably the later :-)
> I am also curious why wf_unregister_sensor() calls wf_put_sensor()
> while wf_register_sensor() doesn't call wf_get_sensor().
It's quite possible that those code path are a bit buggy and not well
exercised. I don't think people ever unload those modules and we tend to
have that stuff built-in ourselves.
Cheers,
Ben.
^ permalink raw reply
* Re: pci32 code - early_*config*
From: Benjamin Herrenschmidt @ 2009-04-17 7:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development
In-Reply-To: <8393884A-D1B0-4081-980C-CF464A38FD6C@kernel.crashing.org>
On Wed, 2009-04-15 at 01:17 -0500, Kumar Gala wrote:
> Ben,
>
> I was looking at what I need to get some additional bits of PCI code
> building w/your ppc64 booke patches. One thing it looks like we need
> is the early config cycle code. The question I have is do we think we
> still need the null_ops support? Also do we think we every get called
> with a NULL hose?
>
> This is fake_pci_bus() in arch/powerpc/kernel/pci_32.c
Hrm.
I'm not fan of the early config stuff, remind me why we need it ?
Ben.
^ permalink raw reply
* Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems
From: Roderick Colenbrander @ 2009-04-17 7:16 UTC (permalink / raw)
To: avorontsov; +Cc: linux-ide, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <20090416220451.GA8636@oksana.dev.rtsoft.ru>
On Fri, Apr 17, 2009 at 12:04 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> On Thu, Apr 16, 2009 at 11:27:34PM +0200, Roderick Colenbrander wrote:
>> On Thu, Apr 16, 2009 at 10:57 PM, Anton Vorontsov
>> <avorontsov@ru.mvista.com> wrote:
>> > On Thu, Apr 16, 2009 at 09:30:00PM +0200, Bartlomiej Zolnierkiewicz wr=
ote:
>> >>
>> >> Hi,
>> >>
>> >> On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote:
>> >> > Hi,
>> >> >
>> >> > I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a
>> >> > Virtex-5 FPGA. The board also contains a ALI M1533 south bridge
>> >> > for IDE, USB and Audio. I did a lot of work to get the pci bus work=
ing
>> >> > on this board and it works correctly but the default init code
>> >> > of the alim15x3 driver doesn't work for me. The driver explicitly
>> >> > disabled some initialization code for powerpc after uncommenting th=
is
>> >> > code it works properly. Benjamin Herrenschmidt and I think this
>> >> > !CONFIG_PPC check should be removed because the system behaves
>> >> > like a real 'x86' system (also the i8259 interrupt controller is us=
ed).
>> >>
>> >> Ben, I guess you are OK with the change and there are no longer other
>> >> platforms requiring CONFIG_PPC check below? =A0[I don't see your ACK =
here]
>> >
>> > I'd like to nak this patch. It'll break MPC8610HPCD boards.
>> >
>> > See commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3
>> >
>> > I'm not sure how should we handle this for Xilinx PPC, MPC8610
>> > PPC and Sparc all at the same time, but it's obvious that #ifdef
>> > isn't enough any longer...
>> >
>> >
>> >
>>
>> If it is really a board specific issue (in case of powerpc it appears
>> to be one) we could also use the default_irq override in ppc_md. What
>> do you think?
>
> Um, I don't see "default_irq" in the ppc_md. Do you want to add one?
>
> I wonder if DECLARE_PCI_FIXUP_*() mechanism will work... see
> arch/powerpc/platforms/fsl_uli1575.c as an example for board-specific
> PCI fixups.
It seems default_irq was the name on old kernels. These days it is
called pci_get_legacy_ide_irq.
Roderick
^ permalink raw reply
* Re: Proposed prom parse fix + moving.
From: Grant Likely @ 2009-04-17 6:44 UTC (permalink / raw)
To: monstr; +Cc: ilpo.jarvinen, linuxppc-dev, Arnd Bergmann
In-Reply-To: <49E81CED.1000704@monstr.eu>
On Fri, Apr 17, 2009 at 12:08 AM, Michal Simek <monstr@monstr.eu> wrote:
> Hi All,
>
> I have got email from Ilpo about prom_parse file.
> I take this file from powerpc. Who did write prom_parse file and take car=
e about?
Posting to the linuxppc-dev list is sufficient to start. There are
several people who may be interested.
> BTW: What about to move prom_parse file to any generic location as we dis=
cussed in past?
> Any volunteer?
I'm kind of working on it. More specifically, I'm looking at
factoring out fdt stuff into common code (drivers/of/of_fdt.c). But I
haven't made a whole lot of progress yet.
> -------- Original Message --------
> Subject: [RFC!] [PATCH] microblaze: fix bug in error handling
> Date: Thu, 16 Apr 2009 23:05:53 +0300 (EEST)
> From: Ilpo J=E4rvinen <ilpo.jarvinen@helsinki.fi>
> To: monstr@monstr.eu
> CC: microblaze-uclinux@itee.uq.edu.au
>
> While some version of the patches were on the lkml I read
> some part of the code briefly through but my feedback got
> stuck into postponed emails, so here's one correctness
> related issue I might have found (the rest were just
> cosmetic things).
>
> I'm not sure if the latter return needs the of_node_put or not
> but it seems more likely than not.
Yes, it does. This change is applicable to
arch/powerpc/kernel/prom_parse.c too.
>
> Not even compile tested.
>
> Signed-off-by: Ilpo J=E4rvinen <ilpo.jarvinen@helsinki.fi>
> ---
> =A0arch/microblaze/kernel/prom_parse.c | =A0 11 +++++++----
> =A01 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel=
/prom_parse.c
> index ae0352e..d1174bc 100644
> --- a/arch/microblaze/kernel/prom_parse.c
> +++ b/arch/microblaze/kernel/prom_parse.c
> @@ -927,20 +927,23 @@ int of_irq_map_one(struct device_node *device,
> =A0 =A0 =A0 =A0/* Get size of interrupt specifier */
> =A0 =A0 =A0 =A0tmp =3D of_get_property(p, "#interrupt-cells", NULL);
> =A0 =A0 =A0 =A0if (tmp =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_node_put(p);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 res =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0intsize =3D *tmp;
>
> =A0 =A0 =A0 =A0pr_debug(" intsize=3D%d intlen=3D%d\n", intsize, intlen);
>
> =A0 =A0 =A0 =A0/* Check index */
> - =A0 =A0 =A0 if ((index + 1) * intsize > intlen)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> + =A0 =A0 =A0 if ((index + 1) * intsize > intlen) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 res =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> + =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0/* Get new specifier and map it */
> =A0 =A0 =A0 =A0res =3D of_irq_map_raw(p, intspec + index * intsize, intsi=
ze,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0addr, out_=
irq);
> +out:
> =A0 =A0 =A0 =A0of_node_put(p);
> =A0 =A0 =A0 =A0return res;
> =A0}
> --
> 1.5.6.5
>
>
> --
> Michal Simek, Ing. (M.Eng)
> w: www.monstr.eu p: +42-0-721842854
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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