* Re: [PATCH] powerpc: Dynamically allocate pacas
From: Michael Ellerman @ 2010-01-27 22:47 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <4389.1264575576@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]
On Wed, 2010-01-27 at 17:29 +1030, Michael Neuling wrote:
> > On 64-bit kernels we currently have a 512 byte struct paca_struct for
> > each cpu (usually just called "the paca"). Currently they are statically
> > allocated, which means a kernel built for a large number of cpus will
> > waste a lot of space if it's booted on a machine with few cpus.
> >
> > We can avoid that by only allocating the number of pacas we need at
> > boot. However this is complicated by the fact that we need to access
> > the paca before we know how many cpus there are in the system.
> >
> > The solution is to dynamically allocate enough space for NR_CPUS pacas,
> > but then later in boot when we know how many cpus we have, we free any
> > unused pacas.
> >
> > Lightly booted on Legacy iSeries & pSeries LPAR.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>
> <snip>
>
> > --- a/arch/powerpc/kernel/setup-common.c
> > +++ b/arch/powerpc/kernel/setup-common.c
> > @@ -493,6 +493,8 @@ void __init smp_setup_cpu_maps(void)
> > * here will have to be reworked
> > */
> > cpu_init_thread_core_maps(nthreads);
> > +
> > + free_unused_pacas();
>
> This is still barfing for me on 32bit.
Darn, what config? I built at least one :)
> Putting an #include <asm/paca.h> at the top of setup-common.c fixes it.
Gah, I saw it was coming via somewhere else but decided not to add it,
wrong decision :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] PCI-E broken on PPC (regression)
From: Benjamin Herrenschmidt @ 2010-01-27 22:00 UTC (permalink / raw)
To: Jesse Barnes
Cc: Linux PCI, Jay Vosburgh, David Miller, Ron Mercer,
kaneshige.kenji, linuxppc-dev, Breno Leitao
In-Reply-To: <20100127082624.4a91323a@jbarnes-piketon>
On Wed, 2010-01-27 at 08:26 -0800, Jesse Barnes wrote:
>
> Thanks Ben. Any refactoring we need to handle this stuff better is
> fine with me too. I guess on some platforms calling pci_setup_device
> may cause problems with special platform devices?
Well, we don't call pci_setup_device() because part of the deal is to
avoid all of that config space reading that it does :-) Especially in
the case of some of the IBM EADS bridges which don't let you access
everything we may want.
Cheers,
Ben.
^ permalink raw reply
* USB host on 83xx
From: Gary Thomas @ 2010-01-27 20:20 UTC (permalink / raw)
To: linuxppc-dev
I have two nearly identical boards, with very different behavior.
Older 8347 (PVR: 0x80830011)
New 8347 (PVR: 0x80830031)
I've tried a number of kernels (vintages) on both with wild results.
2.6.20 - Same kernel works on both(*)
2.6.28 - Kernel runs great on OLD, machine check on NEW
2.6.32.6 - Ditto
The problem occurs (only on the new silicon) during the USB host
initialization. The root hub is found and initialized, then the
EHCI subsystem is reset (to force it to find siblings on the bus).
This results in a machine check at the point where the PHY is
being reinitialized.
I've peppered the driver with messages - here's what I see:
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
********** ehci_fsl_setup.272
********** ehci_fsl_setup.296
********** ehci_fsl_setup.299
********** ehci_fsl_reinit.257
********** mpc83xx_usb_setup.192
********** mpc83xx_usb_setup.207
********** mpc83xx_usb_setup.215
********** mpc83xx_usb_setup.220
********** mpc83xx_setup_phy.163
********** mpc83xx_setup_phy.180
********** mpc83xx_setup_phy.182
********** mpc83xx_usb_setup.238
********** mpc83xx_usb_setup.245
********** mpc83xx_usb_setup.249
********** mpc83xx_usb_setup.251
********** ehci_fsl_reinit.259
********** ehci_hub_control.559 - req: 8961
********** ehci_hub_control.574
********** ehci_hub_control.559 - req: 8961
********** ehci_hub_control.574
********** ehci_fsl_reinit.261
********** ehci_fsl_setup.301
fsl-ehci fsl-ehci.0: irq 39, io base 0xff022000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
********** ehci_hub_control.559 - req: 40966
********** ehci_hub_control.637
hub 1-0:1.0: 2 ports detected
********** ehci_hub_control.559 - req: 40960
********** ehci_hub_control.642
********** ehci_hub_control.559 - req: 8963
********** ehci_hub_control.805
********** ehci_hub_control.559 - req: 8963
********** ehci_hub_control.805
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: Freescale On-Chip EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.28 ehci_hcd
usb usb1: SerialNumber: fsl-ehci.0
fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
********** ehci_fsl_setup.272
********** ehci_fsl_setup.296
********** ehci_fsl_setup.299
********** ehci_fsl_reinit.257
********** mpc83xx_usb_setup.192
********** mpc83xx_usb_setup.207
********** mpc83xx_usb_setup.215
********** mpc83xx_setup_phy.163
********** mpc83xx_setup_phy.180
MACHINE CHECK - so dead it can't even print the message!
At this point, it should carry on like this:
********** ehci_hub_control.559 - req: 8963
********** ehci_hub_control.805
********** ehci_hub_control.559 - req: 41728
********** ehci_hub_control.648
********** ehci_hub_control.559 - req: 8961
********** ehci_hub_control.574
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-1: Product: USB2.0 Hub
********** ehci_hub_control.559 - req: 41728
********** ehci_hub_control.648
You can see that it successfully found the connected external HUB.
Any ideas why this happens? This [basic] code used to work (2.6.20)
on both platforms. I know that's a long time ago, but MACHINE CHECK??
(*) To get this platform to run 2.6.20, I had to patch the CPU tables
to recognize it as 8347 (kernels of that vintage relied on the SVR to
make choices, not PVR)
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 3/8 v2] mtd: Add MPC5121 NAND Flash Controller driver
From: Wolfgang Denk @ 2010-01-27 20:24 UTC (permalink / raw)
To: Grant Likely
Cc: Piotr Ziecik, dzu, linuxppc-dev, linux-mtd, Anatolij Gustschin
In-Reply-To: <fa686aa41001270843u3b4e9687k699ad579de4460d4@mail.gmail.com>
Dear Grant Likely,
In message <fa686aa41001270843u3b4e9687k699ad579de4460d4@mail.gmail.com> you wrote:
>
> > + if (rev != 2) {
> > + dev_err(dev, "SoC revision %u is not supported!\n", rev);
> > + return -ENXIO;
> > + }
>
> *Only* revision 2? Are future revisions of silicon assumed to be broken then?
I vote for keeping it this way - if you look at the diffferences
between revision 1 and 2, or at differences between MPC5121/3 and
MPC5125, it is more than likely that revision 3, should it ever come
out, will be incompatible and require driver changes.
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
Landru! Guide us!
-- A Beta 3-oid, "The Return of the Archons", stardate 3157.4
^ permalink raw reply
* Re: [PATCH 1/2] eeh: Fixing a bug when pci structure is null
From: Linas Vepstas @ 2010-01-27 19:09 UTC (permalink / raw)
To: leitao; +Cc: linuxppc-dev
In-Reply-To: <0642ead63df1b9fdced24750eb0aea940f0408b7.1264617281.git.root@sanx1002.austin.ibm.com>
Hi,
Yes, that's really my sign off: I discussed this at length with Breno.
One comment:
2010/1/27 <leitao@linux.vnet.ibm.com>:
> During a EEH recover, the pci_dev structure can be null,
It can be null when an error is detected during device config (i.e. via
pci config space access through open firmware, using the OF device
node, instead of mmio/dma access), before the kernel has created
a pci_dev structure for the device.
Oddly enough, either this slipped through the cracks all this time,
or maybe pci_name() used to protect against nulls? Not sure.
-- Linas Vepstas
^ permalink raw reply
* [PATCH 2/2] eeh: fixing pci_dev dependency
From: leitao @ 2010-01-27 18:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Linas Vepstas, Breno Leitao
In-Reply-To: <0642ead63df1b9fdced24750eb0aea940f0408b7.1264617281.git.root@sanx1002.austin.ibm.com>
Currently pci_dev can be null when EEH is in action. This patch
just assure that we pci_dev is not NULL before calling pci_dev_put.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
---
arch/powerpc/platforms/pseries/eeh_event.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh_event.c b/arch/powerpc/platforms/pseries/eeh_event.c
index ec5df8f..7956e46 100644
--- a/arch/powerpc/platforms/pseries/eeh_event.c
+++ b/arch/powerpc/platforms/pseries/eeh_event.c
@@ -85,7 +85,8 @@ static int eeh_event_handler(void * dummy)
pdn = handle_eeh_events(event);
eeh_clear_slot(event->dn, EEH_MODE_RECOVERING);
- pci_dev_put(event->dev);
+ if (event->dev)
+ pci_dev_put(event->dev);
kfree(event);
mutex_unlock(&eeh_event_mutex);
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/2] eeh: Fixing a bug when pci structure is null
From: leitao @ 2010-01-27 18:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Linas Vepstas, Breno Leitao
During a EEH recover, the pci_dev structure can be null, and currently
the kernel is crashing when pci_dev is null, with the following message:
Unable to handle kernel paging request for data at address 0x000000a0
Faulting instruction address: 0xc00000000006b8b4
Oops: Kernel access of bad area, sig: 11 [#1]
NIP [c00000000006b8b4] .eeh_event_handler+0x10c/0x1a0
LR [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0
Call Trace:
[c0000003a80dff00] [c00000000006b8a8] .eeh_event_handler+0x100/0x1a0
[c0000003a80dff90] [c000000000031f1c] .kernel_thread+0x54/0x70
The bug occurs because pci_name() tries to access a null pointer.
This patch just guarantee that pci_name() is not called on Null pointers.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/platforms/pseries/eeh.c | 4 ++--
arch/powerpc/platforms/pseries/eeh_driver.c | 11 +++++++++--
arch/powerpc/platforms/pseries/eeh_event.c | 2 +-
4 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 66ea9b8..f860f56 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -49,6 +49,7 @@ unsigned long eeh_check_failure(const volatile void __iomem *token,
unsigned long val);
int eeh_dn_check_failure(struct device_node *dn, struct pci_dev *dev);
void __init pci_addr_cache_build(void);
+const char *eeh_pci_name(struct pci_dev *pdev);
/**
* eeh_add_device_early
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index ccd8dd0..f9360fe 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -491,7 +491,7 @@ int eeh_dn_check_failure(struct device_node *dn, struct pci_dev *dev)
pdn->eeh_mode & EEH_MODE_NOCHECK) {
ignored_check++;
pr_debug("EEH: Ignored check (%x) for %s %s\n",
- pdn->eeh_mode, pci_name (dev), dn->full_name);
+ pdn->eeh_mode, eeh_pci_name (dev), dn->full_name);
return 0;
}
@@ -515,7 +515,7 @@ int eeh_dn_check_failure(struct device_node *dn, struct pci_dev *dev)
printk (KERN_ERR "EEH: %d reads ignored for recovering device at "
"location=%s driver=%s pci addr=%s\n",
pdn->eeh_check_count, location,
- dev->driver->name, pci_name(dev));
+ dev->driver->name, eeh_pci_name(dev));
printk (KERN_ERR "EEH: Might be infinite loop in %s driver\n",
dev->driver->name);
dump_stack();
diff --git a/arch/powerpc/platforms/pseries/eeh_driver.c b/arch/powerpc/platforms/pseries/eeh_driver.c
index ef8e454..afdddf6 100644
--- a/arch/powerpc/platforms/pseries/eeh_driver.c
+++ b/arch/powerpc/platforms/pseries/eeh_driver.c
@@ -41,6 +41,13 @@ static inline const char * pcid_name (struct pci_dev *pdev)
return "";
}
+inline const char *eeh_pci_name(struct pci_dev *pdev)
+{
+ if (NULL==pdev)
+ return "<null>";
+ return pci_name(pdev);
+}
+
#if 0
static void print_device_node_tree(struct pci_dn *pdn, int dent)
{
@@ -337,7 +344,7 @@ struct pci_dn * handle_eeh_events (struct eeh_event *event)
location = location ? location : "unknown";
printk(KERN_ERR "EEH: Error: Cannot find partition endpoint "
"for location=%s pci addr=%s\n",
- location, pci_name(event->dev));
+ location, eeh_pci_name(event->dev));
return NULL;
}
@@ -368,7 +375,7 @@ struct pci_dn * handle_eeh_events (struct eeh_event *event)
pci_str = pci_name (frozen_pdn->pcidev);
drv_str = pcid_name (frozen_pdn->pcidev);
} else {
- pci_str = pci_name (event->dev);
+ pci_str = eeh_pci_name (event->dev);
drv_str = pcid_name (event->dev);
}
diff --git a/arch/powerpc/platforms/pseries/eeh_event.c b/arch/powerpc/platforms/pseries/eeh_event.c
index ddb80f5..ec5df8f 100644
--- a/arch/powerpc/platforms/pseries/eeh_event.c
+++ b/arch/powerpc/platforms/pseries/eeh_event.c
@@ -80,7 +80,7 @@ static int eeh_event_handler(void * dummy)
eeh_mark_slot(event->dn, EEH_MODE_RECOVERING);
printk(KERN_INFO "EEH: Detected PCI bus error on device %s\n",
- pci_name(event->dev));
+ eeh_pci_name(event->dev));
pdn = handle_eeh_events(event);
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH 5/8 v2] powerpc/mpc5121: add USB host support
From: Grant Likely @ 2010-01-27 16:54 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, linux-usb, Bruce Schmid, wd, dzu
In-Reply-To: <1264594052-20317-6-git-send-email-agust@denx.de>
On Wed, Jan 27, 2010 at 5:07 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Platform specific code for MPC5121 USB Host support.
> MPC5121 Rev 2.0 silicon EHCI registers are big endian.
> Add appropriate support by specifying "fsl,big-endian-regs"
> property in device tree node for USB controller. Also
> allow specifying DRVVBUS and PWR_FAULT signal polarity
> of the MPC5121 internal PHY using "fsl,invert-drvvbus" and
> "fsl,invert-pwr-fault" properties.
[...]
> --- a/Documentation/powerpc/dts-bindings/fsl/usb.txt
> +++ b/Documentation/powerpc/dts-bindings/fsl/usb.txt
> @@ -33,6 +33,14 @@ Recommended properties :
> =A0- interrupt-parent : the phandle for the interrupt controller that
> =A0 =A0services interrupts for this device.
>
> +Optional properties :
> + - fsl,big-endian-regs : boolean; if defined, indicates the USB host
> + =A0 controller registers format is big endian.
As commented in previous thread, this property should be dropped, and
the driver should test for fsl,mpc5121-usb2-dr directly. fsl-usb2-dr
should also be dropped from the compatible list of the .dts file.
g.
^ permalink raw reply
* Re: [PATCH 08/11] powerpc/mpc5121: add USB host support
From: Grant Likely @ 2010-01-27 16:52 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, devicetree-discuss, linux-usb, wd, dzu
In-Reply-To: <20100125180024.1a850578@wker>
On Mon, Jan 25, 2010 at 10:00 AM, Anatolij Gustschin <agust@denx.de> wrote:
> On Thu, 21 Jan 2010 10:43:34 -0700
> Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> > diff --git a/Documentation/powerpc/dts-bindings/fsl/usb.txt b/Document=
ation/powerpc/dts-bindings/fsl/usb.txt
>> > index b001524..9050154 100644
>> > --- a/Documentation/powerpc/dts-bindings/fsl/usb.txt
>> > +++ b/Documentation/powerpc/dts-bindings/fsl/usb.txt
>> > @@ -33,6 +33,14 @@ Recommended properties :
>> > =A0- interrupt-parent : the phandle for the interrupt controller that
>> > =A0 =A0services interrupts for this device.
>> >
>> > +Optional properties :
>>
>> > + - big-endian-regs : boolean; if defined, indicates the USB host
>> > + =A0 controller registers format is big endian.
>>
>> Rather than testing for this explicitly, add fsl,mpc5121-usb2-dr to
>> the match table and use the .data pointer for setting device specific
>> quirks.
Still, don't use a new property to describe this. The regs being
big-endian is all wrapped up in the definition of what
fsl,mpc5121-usb2-dr means. You should also drop fsl-usb2-dr from the
compatible list in the .dts file since this device is *not* compatible
with it due to the endian difference. Test for fsl,mpc5121-usb2-dr
explicitly, and adapt the driver behaviour accordingly.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/8 v2] mtd: Add MPC5121 NAND Flash Controller driver
From: Grant Likely @ 2010-01-27 16:43 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: wd, dzu, linuxppc-dev, linux-mtd, Piotr Ziecik
In-Reply-To: <1264594052-20317-4-git-send-email-agust@denx.de>
On Wed, Jan 27, 2010 at 5:07 AM, Anatolij Gustschin <agust@denx.de> wrote:
> From: Piotr Ziecik <kosmo@semihalf.com>
Again, it is appropriate for you to claim patch ownership now as long
as you preserve the signed-off-by history.
>
> Adds NAND Flash Controller driver for MPC5121 Revision 2.
> All device features, except hardware ECC and power management,
> are supported.
A few comments below.
> diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/=
platforms/512x/mpc512x_shared.c
> index 4745028..6b8314c 100644
> --- a/arch/powerpc/platforms/512x/mpc512x_shared.c
> +++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
> @@ -82,6 +82,7 @@ void __init mpc512x_init_IRQ(void)
> =A0static struct of_device_id __initdata of_bus_ids[] =3D {
> =A0 =A0 =A0 =A0{ .compatible =3D "fsl,mpc5121-immr", },
> =A0 =A0 =A0 =A0{ .compatible =3D "fsl,mpc5121-localbus", },
> + =A0 =A0 =A0 { .compatible =3D "fsl,mpc5121-nfc", },
> =A0 =A0 =A0 =A0{},
> =A0};
This hunk shouldn't be in this patch since it touches arch code. Keep
the NAND and arch bits in separate patches.
Also, this is probably not what you really want. Doing it this way
means that each of the child nodes also get registered as of_platform
devices. You want the platform code to only register the nfc@40000000
node.
> +static int __init mpc5121_nfc_probe(struct of_device *op,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 const struct of_device_id *match)
__devinit
> +{
> + =A0 =A0 =A0 struct device_node *rootnode, *dn =3D op->node;
> + =A0 =A0 =A0 struct device *dev =3D &op->dev;
> + =A0 =A0 =A0 struct mpc5121_nfc_prv *prv;
> + =A0 =A0 =A0 struct resource res;
> + =A0 =A0 =A0 struct mtd_info *mtd;
> +#ifdef CONFIG_MTD_PARTITIONS
> + =A0 =A0 =A0 struct mtd_partition *parts;
> +#endif
> + =A0 =A0 =A0 struct nand_chip *chip;
> + =A0 =A0 =A0 unsigned long regs_paddr, regs_size;
> + =A0 =A0 =A0 const uint *chips_no;
> + =A0 =A0 =A0 int resettime =3D 0;
> + =A0 =A0 =A0 int retval =3D 0;
> + =A0 =A0 =A0 int rev, len;
> +
> + =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0* Check SoC revision. This driver supports only NFC
> + =A0 =A0 =A0 =A0* in MPC5121 revision 2.
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 rev =3D (mfspr(SPRN_SVR) >> 4) & 0xF;
> + =A0 =A0 =A0 if (rev !=3D 2) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(dev, "SoC revision %u is not suppor=
ted!\n", rev);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENXIO;
> + =A0 =A0 =A0 }
*Only* revision 2? Are future revisions of silicon assumed to be broken th=
en?
> +static int __exit mpc5121_nfc_remove(struct of_device *op)
__devexit
> +static struct of_device_id mpc5121_nfc_match[] =3D {
...match[] __devinitdata =3D {
> + =A0 =A0 =A0 { .compatible =3D "fsl,mpc5121-nfc", },
> + =A0 =A0 =A0 {},
> +};
> +
> +static struct of_platform_driver mpc5121_nfc_driver =3D {
> + =A0 =A0 =A0 .match_table =A0 =A0=3D mpc5121_nfc_match,
> + =A0 =A0 =A0 .probe =A0 =A0 =A0 =A0 =A0=3D mpc5121_nfc_probe,
> + =A0 =A0 =A0 .remove =A0 =A0 =A0 =A0 =3D __exit_p(mpc5121_nfc_remove),
__devexit_p()
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/pci: Add calls to set_pcie_port_type() and set_pcie_hotplug_bridge()
From: Jesse Barnes @ 2010-01-27 16:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux PCI, linuxppc-dev, Breno Leitao
In-Reply-To: <1264561803.3601.163.camel@pasglop>
On Wed, 27 Jan 2010 14:10:03 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> We are missing these when building the pci_dev from scratch off
> the Open Firmware device-tree
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/kernel/pci_of_scan.c | 2 ++
> drivers/pci/probe.c | 4 ++--
> include/linux/pci.h | 4 ++++
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
> Jesse, can I have an ack for the generic bits ? Note that I couldn't test
> on a pSeries machine with PCI-E as all such machines in ozlabs currently
> have all their partitions with PCI-E devices in them in FAIL state in ABAT
> and our admin is out.
Yeah, generic bits look fine.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [RFC PATCH] PCI-E broken on PPC (regression)
From: Jesse Barnes @ 2010-01-27 16:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux PCI, Jay Vosburgh, David Miller, Ron Mercer,
kaneshige.kenji, linuxppc-dev, Breno Leitao
In-Reply-To: <1264558256.3601.153.camel@pasglop>
On Wed, 27 Jan 2010 13:10:56 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Cc'ing Ben for PPC. Ben, should PPC use pci_scan_device when probing
> > its root busses? Sounds like it just uses pci_device_add for each one
> > it finds instead?
> >
> > If you don't actually need scanning (though what about hotplug?) we can
> > move the call to device_add instead...
>
> Ok so I looked at the code and the problem goes way beyond root busses.
>
> Basically, powerpc can use the code in arch/powerpc/kernel/pci_of_scan.c
> to "generate" the pci_dev without using config space probing or at least
> using as little of it as possible, using the firmware device-tree
> information instead.
>
> This is also probably going to be moved to a more generic place and
> extended to be used optionally by other architectures.
>
> I think sparc does something similar in fact in arch/sparc/kernel/pci.c
> (of_create_pci_dev()) though it would be logical to have sparc and
> powerpc share the same implementation here in the long run and I believe
> Grant Likely is working on it.
>
> That means that potentially, pci_dev will be created on those archs for
> which pci_setup_device() is never called. Thus we need to be very
> careful when adding initializations there that at least we (myself and
> davem) are notified of that so we can mirror them in our code, or even
> better, if people doing so put them there too...
>
> So as far as I can tell, we are missing that set_pcie_port_type(), so we
> need to add it to sparc and powerpc (and so make the function non-static
> in drivers/pci/probe.c). We are also missing the manipulation of
> dev->slot in fact, so that will need to be fixed too.
>
> set_pcie_hotplug_bridge() might be something we want to add too, it's
> not totally clear yet due to possible issues with our firmwares.
> pci_fixup_device(pci_fixup_early,...) as well in fact.
>
> I'll try do make ppc catch up with some of that see how it goes.
Thanks Ben. Any refactoring we need to handle this stuff better is
fine with me too. I guess on some platforms calling pci_setup_device
may cause problems with special platform devices?
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 0/3 for 2.6.33] Some fixes for kfifo and FHCI
From: Stefani Seibold @ 2010-01-27 15:47 UTC (permalink / raw)
To: Greg KH
Cc: linux-usb, linux-kernel, linuxppc-dev, Andrew Morton,
Anton Vorontsov
In-Reply-To: <20100127145054.GA24673@suse.de>
Am Mittwoch, den 27.01.2010, 06:50 -0800 schrieb Greg KH:
> On Wed, Jan 27, 2010 at 05:08:09PM +0300, Anton Vorontsov wrote:
> > Hi all,
> >
> > FHCI no longer builds after kfifo rework, this patch set is
> > used to fix the issues.
>
> If there are no objections to these, I'll queue these up and send them
> through my tree as they affect the FHCI driver.
>
Looks good for me, so
Acked-by: Stefani Seibold <stefani@seibold.net>
^ permalink raw reply
* Re: [PATCH 2/8 v2] rtc: Add MPC5121 Real time clock driver
From: Grant Likely @ 2010-01-27 15:58 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: wd, rtc-linux, linuxppc-dev, dzu, Piotr Ziecik
In-Reply-To: <1264594052-20317-3-git-send-email-agust@denx.de>
On Wed, Jan 27, 2010 at 5:07 AM, Anatolij Gustschin <agust@denx.de> wrote:
> From: John Rigby <jcrigby@gmail.com>
This is your patch now. You can claim authorship in the git commit record.
> Based on Domen Puncer's rtc driver for 5200.
> Changes to Domen's original:
>
> =A0 =A0Changed filenames/routine names from mpc5200* to mpc5121*
> =A0 =A0Changed match to only care about compatible and use "fsl,"
> =A0 =A0convention for compatible.
>
> =A0 =A0Make alarms more sane by dealing with lack of second alarm
> =A0 =A0resolution.
>
> =A0 =A0Deal with the fact that most of the 5121 rtc registers are not
> =A0 =A0persistent across a reset even with a battery attached:
>
> =A0 =A0 =A0 =A0Use actual_time register for time keeping
> =A0 =A0 =A0 =A0and target_time register as an offset to linux time
>
> =A0 =A0 =A0 =A0The target_time register would normally be used for hibern=
ation
> =A0 =A0 =A0 =A0but hibernation does not work on current silicon
This is a description of what has been done, but it is not a
description of what the patch is. Think about it this way, if someone
looks at your commit in git after it is merged, will the above text
make sense?
>
> Signed-off-by: John Rigby <jcrigby@gmail.com>
> Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: <rtc-linux@googlegroups.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: John Rigby <jcrigby@gmail.com>
> ---
> Changes since v1 (as requested by Alessandro Zummo):
> =A0- Remove history from the driver file, the same history is in
> =A0 commit message
> =A0- implement alarm/irq interface using ->ops structure, don't
> =A0 use ops->ioctl() any more
> =A0- Clean up probe()
> =A0- replace printk() by dev_*()
> =A0- add arch dependency in Kconfig
> =A0- add requested include linux/init.h
> =A0- move MODULE_XXX to the end
> =A0- use rtc_valid_tm() when returning 'tm'
> =A0- use __init/__exit/__exit_p as this is not a hotpluggable device
Dangerous. You're assuming that drivers won't be able to be
bound/rebound at runtime. The kernel has no idea you've done this,
and it will cause a bug. You should always use
__devinit/__devexit/__devexit_p for the probe/remove hooks in
of_platform drivers.
> +static int __init mpc5121_rtc_probe(struct of_device *op,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 const struct of_device_id *match)
__devinit
> +{
> + =A0 =A0 =A0 struct mpc5121_rtc_data *rtc;
> + =A0 =A0 =A0 int err =3D 0;
> + =A0 =A0 =A0 u32 ka;
> +
> + =A0 =A0 =A0 rtc =3D kzalloc(sizeof(*rtc), GFP_KERNEL);
> + =A0 =A0 =A0 if (!rtc)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOMEM;
> +
> + =A0 =A0 =A0 rtc->regs =3D of_iomap(op->node, 0);
> + =A0 =A0 =A0 if (!rtc->regs) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&op->dev, "%s: couldn't map io spac=
e\n", __func__);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D -ENOSYS;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_free;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 device_init_wakeup(&op->dev, 1);
> +
> + =A0 =A0 =A0 rtc->rtc =3D rtc_device_register("mpc5121-rtc", &op->dev,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 &mpc5121_rtc_ops, THIS_MODULE);
> + =A0 =A0 =A0 if (IS_ERR(rtc->rtc)) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 err =3D PTR_ERR(rtc->rtc);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_unmap;
> + =A0 =A0 =A0 }
I haven't dug into the rtc layer, but this looks racy. The device is
getting registered before it is completely set up (irq not mapped,
keepalive register not initialized). Is this correct?
> +
> + =A0 =A0 =A0 dev_set_drvdata(&op->dev, rtc);
> +
> + =A0 =A0 =A0 rtc->irq =3D irq_of_parse_and_map(op->node, 1);
> + =A0 =A0 =A0 err =3D request_irq(rtc->irq, mpc5121_rtc_handler, IRQF_DIS=
ABLED,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 "mpc5121-rtc", &op->dev);
> + =A0 =A0 =A0 if (err) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&op->dev, "%s: could not request ir=
q: %i\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __func__, rtc->irq);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_dispose;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 rtc->irq_periodic =3D irq_of_parse_and_map(op->node, 0);
> + =A0 =A0 =A0 err =3D request_irq(rtc->irq_periodic, mpc5121_rtc_handler_=
upd,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IRQF_DISABL=
ED, "mpc5121-rtc_upd", &op->dev);
> + =A0 =A0 =A0 if (err) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&op->dev, "%s: could not request ir=
q: %i\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 __func__, rtc->irq_periodic);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_dispose2;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 ka =3D in_be32(&rtc->regs->keep_alive);
> + =A0 =A0 =A0 if (ka & 0x02) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_warn(&op->dev,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "mpc5121-rtc: Battery or os=
cillator failure!\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 out_be32(&rtc->regs->keep_alive, ka);
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 return 0;
> +
> +out_dispose2:
> + =A0 =A0 =A0 irq_dispose_mapping(rtc->irq_periodic);
> + =A0 =A0 =A0 free_irq(rtc->irq, &op->dev);
> +out_dispose:
> + =A0 =A0 =A0 irq_dispose_mapping(rtc->irq);
> +out_unmap:
> + =A0 =A0 =A0 iounmap(rtc->regs);
> +out_free:
> + =A0 =A0 =A0 kfree(rtc);
> +
> + =A0 =A0 =A0 return err;
> +}
> +
> +static int __exit mpc5121_rtc_remove(struct of_device *op)
__devexit
> +{
> + =A0 =A0 =A0 struct mpc5121_rtc_data *rtc =3D dev_get_drvdata(&op->dev);
> + =A0 =A0 =A0 struct mpc5121_rtc_regs __iomem *regs =3D rtc->regs;
> +
> + =A0 =A0 =A0 /* disable interrupt, so there are no nasty surprises */
> + =A0 =A0 =A0 out_8(®s->alm_enable, 0);
> + =A0 =A0 =A0 out_8(®s->int_enable, in_8(®s->int_enable) & ~0x1);
> +
> + =A0 =A0 =A0 rtc_device_unregister(rtc->rtc);
> + =A0 =A0 =A0 iounmap(rtc->regs);
> + =A0 =A0 =A0 free_irq(rtc->irq, &op->dev);
> + =A0 =A0 =A0 free_irq(rtc->irq_periodic, &op->dev);
> + =A0 =A0 =A0 irq_dispose_mapping(rtc->irq);
> + =A0 =A0 =A0 irq_dispose_mapping(rtc->irq_periodic);
> + =A0 =A0 =A0 dev_set_drvdata(&op->dev, NULL);
> + =A0 =A0 =A0 kfree(rtc);
> +
> + =A0 =A0 =A0 return 0;
> +}
> +
> +static struct of_device_id mpc5121_rtc_match[] =3D {
Missing __devinitdata. Should be like this:
static struct of_device_id mpc5121_rtc_match[] __devinitdata =3D {
> + =A0 =A0 =A0 { .compatible =3D "fsl,mpc5121-rtc", },
> + =A0 =A0 =A0 {},
> +};
> +
> +static struct of_platform_driver mpc5121_rtc_driver =3D {
> + =A0 =A0 =A0 .owner =3D THIS_MODULE,
> + =A0 =A0 =A0 .name =3D "mpc5121-rtc",
> + =A0 =A0 =A0 .match_table =3D mpc5121_rtc_match,
> + =A0 =A0 =A0 .probe =3D mpc5121_rtc_probe,
> + =A0 =A0 =A0 .remove =3D __exit_p(mpc5121_rtc_remove),
> +};
> +
> +static int __init mpc5121_rtc_init(void)
> +{
> + =A0 =A0 =A0 return of_register_platform_driver(&mpc5121_rtc_driver);
> +}
> +module_init(mpc5121_rtc_init);
> +
> +static void __exit mpc5121_rtc_exit(void)
> +{
> + =A0 =A0 =A0 of_unregister_platform_driver(&mpc5121_rtc_driver);
> +}
> +module_exit(mpc5121_rtc_exit);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("John Rigby <jcrigby@gmail.com>");
> --
> 1.5.6.3
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/8 v2] powerpc/mpc5121: Add machine restart support
From: Grant Likely @ 2010-01-27 15:46 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev, wd, dzu, Piotr Ziecik
In-Reply-To: <1264594052-20317-2-git-send-email-agust@denx.de>
On Wed, Jan 27, 2010 at 5:07 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Add reset module registers representation and
> machine restart callback for mpc5121 platform.
one comment below.
>
> Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: John Rigby <jcrigby@gmail.com>
> ---
>
> Changes since v1:
> =A0- use 'struct mpc512x_reset_module *' type for 'reset_module_base'
> =A0- remove empty line
> =A0- remove leftover colon and use pr_err() instead of printk.
>
> =A0arch/powerpc/include/asm/mpc5xxx.h =A0 =A0 =A0 =A0 =A0 =A0| =A0 14 +++=
++++++-
> =A0arch/powerpc/platforms/512x/mpc5121_ads.c =A0 =A0 | =A0 =A01 +
> =A0arch/powerpc/platforms/512x/mpc5121_generic.c | =A0 =A01 +
> =A0arch/powerpc/platforms/512x/mpc512x.h =A0 =A0 =A0 =A0 | =A0 =A01 +
> =A0arch/powerpc/platforms/512x/mpc512x_shared.c =A0| =A0 34 +++++++++++++=
++++++++++++
> =A05 files changed, 50 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mpc5xxx.h b/arch/powerpc/include/as=
m/mpc5xxx.h
> index 5ce9c5f..0004986 100644
> --- a/arch/powerpc/include/asm/mpc5xxx.h
> +++ b/arch/powerpc/include/asm/mpc5xxx.h
> @@ -18,5 +18,17 @@
>
> =A0extern unsigned long mpc5xxx_get_bus_frequency(struct device_node *nod=
e);
>
> -#endif /* __ASM_POWERPC_MPC5xxx_H__ */
> +/* MPC512x Reset module registers */
> +struct mpc512x_reset_module {
> + =A0 =A0 =A0 u32 =A0 =A0 rcwlr; =A0/* Reset Configuration Word Low Regis=
ter */
> + =A0 =A0 =A0 u32 =A0 =A0 rcwhr; =A0/* Reset Configuration Word High Regi=
ster */
> + =A0 =A0 =A0 u32 =A0 =A0 reserved1;
> + =A0 =A0 =A0 u32 =A0 =A0 reserved2;
> + =A0 =A0 =A0 u32 =A0 =A0 rsr; =A0 =A0/* Reset Status Register */
> + =A0 =A0 =A0 u32 =A0 =A0 rmr; =A0 =A0/* Reset Mode Register */
> + =A0 =A0 =A0 u32 =A0 =A0 rpr; =A0 =A0/* Reset Protection Register */
> + =A0 =A0 =A0 u32 =A0 =A0 rcr; =A0 =A0/* Reset Control Register */
> + =A0 =A0 =A0 u32 =A0 =A0 rcer; =A0 /* Reset Control Enable Register */
> +};
>
> +#endif /* __ASM_POWERPC_MPC5xxx_H__ */
> diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c b/arch/powerpc/pla=
tforms/512x/mpc5121_ads.c
> index 441abc4..2f40404 100644
> --- a/arch/powerpc/platforms/512x/mpc5121_ads.c
> +++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
> @@ -68,4 +68,5 @@ define_machine(mpc5121_ads) {
> =A0 =A0 =A0 =A0.init_IRQ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D mpc5121_ads_init=
_IRQ,
> =A0 =A0 =A0 =A0.get_irq =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D ipic_get_irq,
> =A0 =A0 =A0 =A0.calibrate_decr =A0 =A0 =A0 =A0 =3D generic_calibrate_decr=
,
> + =A0 =A0 =A0 .restart =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D mpc512x_restart=
,
> =A0};
> diff --git a/arch/powerpc/platforms/512x/mpc5121_generic.c b/arch/powerpc=
/platforms/512x/mpc5121_generic.c
> index 2479de9..de4c3f7 100644
> --- a/arch/powerpc/platforms/512x/mpc5121_generic.c
> +++ b/arch/powerpc/platforms/512x/mpc5121_generic.c
> @@ -55,4 +55,5 @@ define_machine(mpc5121_generic) {
> =A0 =A0 =A0 =A0.init_IRQ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D mpc512x_init_IRQ=
,
> =A0 =A0 =A0 =A0.get_irq =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D ipic_get_irq,
> =A0 =A0 =A0 =A0.calibrate_decr =A0 =A0 =A0 =A0 =3D generic_calibrate_decr=
,
> + =A0 =A0 =A0 .restart =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D mpc512x_restart=
,
> =A0};
> diff --git a/arch/powerpc/platforms/512x/mpc512x.h b/arch/powerpc/platfor=
ms/512x/mpc512x.h
> index 22a5352..c38875c 100644
> --- a/arch/powerpc/platforms/512x/mpc512x.h
> +++ b/arch/powerpc/platforms/512x/mpc512x.h
> @@ -12,5 +12,6 @@
> =A0#ifndef __MPC512X_H__
> =A0#define __MPC512X_H__
> =A0extern void __init mpc512x_init_IRQ(void);
> +extern void mpc512x_restart(char *cmd);
> =A0void __init mpc512x_declare_of_platform_devices(void);
> =A0#endif =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* __MPC512X_H_=
_ */
> diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/=
platforms/512x/mpc512x_shared.c
> index 434d683..4745028 100644
> --- a/arch/powerpc/platforms/512x/mpc512x_shared.c
> +++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
> @@ -21,9 +21,43 @@
> =A0#include <asm/ipic.h>
> =A0#include <asm/prom.h>
> =A0#include <asm/time.h>
> +#include <asm/mpc5xxx.h>
>
> =A0#include "mpc512x.h"
>
> +static struct mpc512x_reset_module __iomem *reset_module_base;
> +
> +static int __init mpc512x_restart_init(void)
> +{
> + =A0 =A0 =A0 struct device_node *np;
> +
> + =A0 =A0 =A0 np =3D of_find_compatible_node(NULL, NULL, "fsl,mpc5121-res=
et");
> + =A0 =A0 =A0 if (!np)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1;
> +
> + =A0 =A0 =A0 reset_module_base =3D of_iomap(np, 0);
> + =A0 =A0 =A0 of_node_put(np);
> +
> + =A0 =A0 =A0 return 0;
> +}
> +arch_initcall(mpc512x_restart_init);
Avoid using arch_initcalls for this sort of thing. Call it explicitly
from your platform code. Doing an arch_initcall means that platform
code cannot override it, and that on a multiplatform kernel it will
get called on non-5121 platforms.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 5/8 v2] powerpc/mpc5121: add USB host support
From: Anatolij Gustschin @ 2010-01-27 15:45 UTC (permalink / raw)
To: Jan Andersson; +Cc: linuxppc-dev, linux-usb, wd, dzu
In-Reply-To: <4B60333C.9040806@gaisler.com>
On Wed, 27 Jan 2010 13:36:12 +0100
Jan Andersson <jan@gaisler.com> wrote:
> Anatolij Gustschin wrote:
> > @@ -259,6 +305,11 @@ static int ehci_fsl_setup(struct usb_hcd *hcd)
> > {
> > struct ehci_hcd *ehci = hcd_to_ehci(hcd);
> > int retval;
> > + struct fsl_usb2_platform_data *pdata;
> > +
> > + pdata = hcd->self.controller->platform_data;
> > + ehci->big_endian_desc = pdata->big_endian_desc;
> > + ehci->big_endian_mmio = pdata->big_endian_mmio;
>
> I recently posted some questions to linux-usb@vger about big_endian_mmio
> and the definition of the HC_LENGTH and HC_VERSION macros. The thread
> can be found here: http://marc.info/?l=linux-usb&m=126441448626924&w=2
>
> The EHCI specification defines the CAPLENGTH register as an 8-bit
> register at byte offset 0 and HCIVERSION as a 16-bit register at byte
> offset 2. Performing a 32-bit read on a big endian system should
> therefore results in the following organisation (MSB .. LSB):
> CAPLENGTH : RESERVED : HCIVERSION
>
> The macros for reading CAPLENGTH and HCIVERSION (defined in
> include/linux/usb/ehci-def.h) look like:
>
> #define HC_LENGTH(p) (((p)>>00)&0x00ff) /* bits 7:0 */
> #define HC_VERSION(p) (((p)>>16)&0xffff) /* bits 31:16 */
>
> That is, they select the registers as they were organized within the
> word according to little endian. Is this not a problem for your
> controller/driver?
On this controller the CAPLENGTH register is an 8-bit regiser at
byte offset 3 and HCIVERSION register is a 16-bit register at
byte offset 0. Performing a 32-bit read results in:
HCIVERSION : RESERVED : CAPLENGTH
So it is not a problem for the driver.
Best regards,
Anatolij
^ permalink raw reply
* Re: [PATCH v2 1/3] i2c-mpc: use __devinit[data] for initialization functions and data
From: Wolfgang Grandegger @ 2010-01-27 15:14 UTC (permalink / raw)
To: Ben Dooks
Cc: Devicetree-discuss, Linuxppc-dev, Linux-i2c, Wolfgang Grandegger
In-Reply-To: <20100127150801.GC6090@fluff.org.uk>
Ben Dooks wrote:
> On Tue, Jan 26, 2010 at 07:44:10PM +0100, Wolfgang Grandegger wrote:
>> Ben Dooks wrote:
>>> On Mon, Jan 25, 2010 at 09:55:04PM +0100, Wolfgang Grandegger wrote:
[snip]
>>> Any particular reason you decided to move this all about?
>> This was necessary to allow using __devinit[data] for the clock setup
>> functions and clock diviver arrays above which results in some notable
>> saving of memory space if the driver is statically linked into the
>> kernel. If the data is defined within "mpc_i2c_of_match", section
>> mismatches are reported.
>>
>>> Are you sure that __devinitdata is the right thing here, I've no idea
>>> if there is currently any hotplug type support for openfirmware or
>>> not.
>> I agree that __init[data] is more appropriate for this driver even if
>> many other non-hotplugable drivers use __devinit[data]. I will change that.
>
> sorry, may have gotten confused by which type of __init is which, I
> think __devinit is the correct one here.
Why? It's not obvious to me how a i2c device might be hotpugged? Will
require v4 to fix it.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [PATCH v2 1/3] i2c-mpc: use __devinit[data] for initialization functions and data
From: Ben Dooks @ 2010-01-27 15:08 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Wolfgang Grandegger, Devicetree-discuss, Linuxppc-dev, Linux-i2c,
Ben Dooks
In-Reply-To: <4B5F37FA.8060809@grandegger.com>
On Tue, Jan 26, 2010 at 07:44:10PM +0100, Wolfgang Grandegger wrote:
> Ben Dooks wrote:
> > On Mon, Jan 25, 2010 at 09:55:04PM +0100, Wolfgang Grandegger wrote:
> >> From: Wolfgang Grandegger <wg@denx.de>
> >>
> >> "__devinit[data]" has not yet been used for all initialization functions
> >> and data. To avoid truncating lines, the struct mpc_i2c_match_data has
> >> been renamed to mpc_i2c_data, which is even the better name.
> >>
> >> Signed-off-by: Wolfgang Grandegger <wg@denx.de>
> >> ---
> >> drivers/i2c/busses/i2c-mpc.c | 99 +++++++++++++++++++----------------------
> >> 1 files changed, 46 insertions(+), 53 deletions(-)
> >>
> >> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> >> index f627001..2cb864e 100644
> >> --- a/drivers/i2c/busses/i2c-mpc.c
> >> +++ b/drivers/i2c/busses/i2c-mpc.c
> >> @@ -66,7 +66,7 @@ struct mpc_i2c_divider {
> >> u16 fdr; /* including dfsrr */
> >> };
> >>
> >> -struct mpc_i2c_match_data {
> >> +struct mpc_i2c_data {
> >> void (*setclock)(struct device_node *node,
> >> struct mpc_i2c *i2c,
> >> u32 clock, u32 prescaler);
> >> @@ -165,7 +165,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> >> }
> >>
> >> #ifdef CONFIG_PPC_MPC52xx
> >> -static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
> >> +static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
> >> {20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
> >> {28, 0x24}, {30, 0x01}, {32, 0x25}, {34, 0x02},
> >> {36, 0x26}, {40, 0x27}, {44, 0x04}, {48, 0x28},
> >> @@ -186,7 +186,8 @@ static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] = {
> >> {10240, 0x9d}, {12288, 0x9e}, {15360, 0x9f}
> >> };
> >>
> >> -int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescaler)
> >> +static int __devinit mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock,
> >> + int prescaler)
> >> {
> >> const struct mpc_i2c_divider *div = NULL;
> >> unsigned int pvr = mfspr(SPRN_PVR);
> >> @@ -215,9 +216,9 @@ int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescaler)
> >> return div ? (int)div->fdr : -EINVAL;
> >> }
> >>
> >> -static void mpc_i2c_setclock_52xx(struct device_node *node,
> >> - struct mpc_i2c *i2c,
> >> - u32 clock, u32 prescaler)
> >> +static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
> >> + struct mpc_i2c *i2c,
> >> + u32 clock, u32 prescaler)
> >> {
> >> int ret, fdr;
> >>
> >> @@ -230,15 +231,15 @@ static void mpc_i2c_setclock_52xx(struct device_node *node,
> >> dev_info(i2c->dev, "clock %d Hz (fdr=%d)\n", clock, fdr);
> >> }
> >> #else /* !CONFIG_PPC_MPC52xx */
> >> -static void mpc_i2c_setclock_52xx(struct device_node *node,
> >> - struct mpc_i2c *i2c,
> >> - u32 clock, u32 prescaler)
> >> +static void __devinit mpc_i2c_setclock_52xx(struct device_node *node,
> >> + struct mpc_i2c *i2c,
> >> + u32 clock, u32 prescaler)
> >> {
> >> }
> >> #endif /* CONFIG_PPC_MPC52xx*/
> >>
> >> #ifdef CONFIG_FSL_SOC
> >> -static const struct mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
> >> +static const struct __devinitdata mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
> >> {160, 0x0120}, {192, 0x0121}, {224, 0x0122}, {256, 0x0123},
> >> {288, 0x0100}, {320, 0x0101}, {352, 0x0601}, {384, 0x0102},
> >> {416, 0x0602}, {448, 0x0126}, {480, 0x0103}, {512, 0x0127},
> >> @@ -258,7 +259,7 @@ static const struct mpc_i2c_divider mpc_i2c_dividers_8xxx[] = {
> >> {49152, 0x011e}, {61440, 0x011f}
> >> };
> >>
> >> -u32 mpc_i2c_get_sec_cfg_8xxx(void)
> >> +static u32 __devinit mpc_i2c_get_sec_cfg_8xxx(void)
> >> {
> >> struct device_node *node = NULL;
> >> u32 __iomem *reg;
> >> @@ -287,7 +288,8 @@ u32 mpc_i2c_get_sec_cfg_8xxx(void)
> >> return val;
> >> }
> >>
> >> -int mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock, u32 prescaler)
> >> +static int __devinit mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock,
> >> + u32 prescaler)
> >> {
> >> const struct mpc_i2c_divider *div = NULL;
> >> u32 divider;
> >> @@ -320,9 +322,9 @@ int mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock, u32 prescaler)
> >> return div ? (int)div->fdr : -EINVAL;
> >> }
> >>
> >> -static void mpc_i2c_setclock_8xxx(struct device_node *node,
> >> - struct mpc_i2c *i2c,
> >> - u32 clock, u32 prescaler)
> >> +static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
> >> + struct mpc_i2c *i2c,
> >> + u32 clock, u32 prescaler)
> >> {
> >> int ret, fdr;
> >>
> >> @@ -338,9 +340,9 @@ static void mpc_i2c_setclock_8xxx(struct device_node *node,
> >> }
> >>
> >> #else /* !CONFIG_FSL_SOC */
> >> -static void mpc_i2c_setclock_8xxx(struct device_node *node,
> >> - struct mpc_i2c *i2c,
> >> - u32 clock, u32 prescaler)
> >> +static void __devinit mpc_i2c_setclock_8xxx(struct device_node *node,
> >> + struct mpc_i2c *i2c,
> >> + u32 clock, u32 prescaler)
> >> {
> >> }
> >> #endif /* CONFIG_FSL_SOC */
> >> @@ -529,8 +531,8 @@ static int __devinit fsl_i2c_probe(struct of_device *op,
> >> clock = *prop;
> >>
> >> if (match->data) {
> >> - struct mpc_i2c_match_data *data =
> >> - (struct mpc_i2c_match_data *)match->data;
> >> + struct mpc_i2c_data *data =
> >> + (struct mpc_i2c_data *)match->data;
> >> data->setclock(op->node, i2c, clock, data->prescaler);
> >> } else {
> >> /* Backwards compatibility */
> >> @@ -582,44 +584,35 @@ static int __devexit fsl_i2c_remove(struct of_device *op)
> >> return 0;
> >> };
> >>
> >> +static struct mpc_i2c_data __devinitdata mpc_i2c_data_52xx = {
> >> + .setclock = mpc_i2c_setclock_52xx,
> >> +};
> >> +
> >> +static struct mpc_i2c_data __devinitdata mpc_i2c_data_8313 = {
> >> + .setclock = mpc_i2c_setclock_8xxx,
> >> +};
> >> +
> >> +static struct mpc_i2c_data __devinitdata mpc_i2c_data_8543 = {
> >> + .setclock = mpc_i2c_setclock_8xxx,
> >> + .prescaler = 2,
> >> +};
> >> +
> >> +static struct mpc_i2c_data __devinitdata mpc_i2c_data_8544 = {
> >> + .setclock = mpc_i2c_setclock_8xxx,
> >> + .prescaler = 3,
> >> +};
> >> +
> >> static const struct of_device_id mpc_i2c_of_match[] = {
> >> - {.compatible = "mpc5200-i2c",
> >> - .data = &(struct mpc_i2c_match_data) {
> >> - .setclock = mpc_i2c_setclock_52xx,
> >> - },
> >> - },
> >> - {.compatible = "fsl,mpc5200b-i2c",
> >> - .data = &(struct mpc_i2c_match_data) {
> >> - .setclock = mpc_i2c_setclock_52xx,
> >> - },
> >> - },
> >> - {.compatible = "fsl,mpc5200-i2c",
> >> - .data = &(struct mpc_i2c_match_data) {
> >> - .setclock = mpc_i2c_setclock_52xx,
> >> - },
> >> - },
> >> - {.compatible = "fsl,mpc8313-i2c",
> >> - .data = &(struct mpc_i2c_match_data) {
> >> - .setclock = mpc_i2c_setclock_8xxx,
> >> - },
> >> - },
> >> - {.compatible = "fsl,mpc8543-i2c",
> >> - .data = &(struct mpc_i2c_match_data) {
> >> - .setclock = mpc_i2c_setclock_8xxx,
> >> - .prescaler = 2,
> >> - },
> >> - },
> >> - {.compatible = "fsl,mpc8544-i2c",
> >> - .data = &(struct mpc_i2c_match_data) {
> >> - .setclock = mpc_i2c_setclock_8xxx,
> >> - .prescaler = 3,
> >> - },
> >> + {.compatible = "mpc5200-i2c", .data = &mpc_i2c_data_52xx, },
> >> + {.compatible = "fsl,mpc5200b-i2c", .data = &mpc_i2c_data_52xx, },
> >> + {.compatible = "fsl,mpc5200-i2c", .data = &mpc_i2c_data_52xx, },
> >> + {.compatible = "fsl,mpc8313-i2c", .data = &mpc_i2c_data_8313, },
> >> + {.compatible = "fsl,mpc8543-i2c", .data = &mpc_i2c_data_8543, },
> >> + {.compatible = "fsl,mpc8544-i2c", .data = &mpc_i2c_data_8544, },
> >> /* Backward compatibility */
> >> - },
> >> {.compatible = "fsl-i2c", },
> >> {},
> >> };
> >
> > Any particular reason you decided to move this all about?
>
> This was necessary to allow using __devinit[data] for the clock setup
> functions and clock diviver arrays above which results in some notable
> saving of memory space if the driver is statically linked into the
> kernel. If the data is defined within "mpc_i2c_of_match", section
> mismatches are reported.
>
> > Are you sure that __devinitdata is the right thing here, I've no idea
> > if there is currently any hotplug type support for openfirmware or
> > not.
>
> I agree that __init[data] is more appropriate for this driver even if
> many other non-hotplugable drivers use __devinit[data]. I will change that.
sorry, may have gotten confused by which type of __init is which, I
think __devinit is the correct one here.
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: [PATCH 0/3 for 2.6.33] Some fixes for kfifo and FHCI
From: Greg KH @ 2010-01-27 14:50 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Stefani Seibold, linux-usb, linux-kernel, linuxppc-dev,
Andrew Morton
In-Reply-To: <20100127140809.GA27906@oksana.dev.rtsoft.ru>
On Wed, Jan 27, 2010 at 05:08:09PM +0300, Anton Vorontsov wrote:
> Hi all,
>
> FHCI no longer builds after kfifo rework, this patch set is
> used to fix the issues.
If there are no objections to these, I'll queue these up and send them
through my tree as they affect the FHCI driver.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/8] Update support for MPC512x
From: Anatolij Gustschin @ 2010-01-27 14:23 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: wd, dzu, linux-usb, linuxppc-dev, linux-mtd, rtc-linux,
Dan Williams
In-Reply-To: <1264594052-20317-1-git-send-email-agust@denx.de>
On Wed, 27 Jan 2010 13:07:24 +0100
Anatolij Gustschin <agust@denx.de> wrote:
> This patch series brings support for the Freescale MPC512x
> processsors up to date:
>
> powerpc/mpc5121: Add machine restart support
> rtc: Add MPC5121 Real time clock driver
> mtd: Add NAND Flash Controller driver
> dma: Add MPC512x DMA driver
> powerpc/mpc5121: add USB host support
> powerpc/mpc5121: shared DIU framebuffer support
> powerpc/mpc5121: update mpc5121ads DTS
> powerpc/mpc5121: Add default config for MPC5121ADS
Now your can also pull these patches from
git://git.denx.de/linux-2.6-denx.git mpc512x-v2.6.33-devel
Branch. FEC Patches for interested people are also provided
in this Branch.
Best regards,
Anatolij
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* [PATCH 3/3] kfifo: Don't use integer as NULL pointer
From: Anton Vorontsov @ 2010-01-27 14:09 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-usb, Stefani Seibold, Greg Kroah-Hartman, linux-kernel,
linuxppc-dev
In-Reply-To: <20100127140809.GA27906@oksana.dev.rtsoft.ru>
This patch fixes following sparse warnings:
include/linux/kfifo.h:127:25: warning: Using plain integer as NULL pointer
kernel/kfifo.c:83:21: warning: Using plain integer as NULL pointer
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
include/linux/kfifo.h | 2 +-
kernel/kfifo.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h
index 6f6c5f3..bc0fc79 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -124,7 +124,7 @@ extern __must_check unsigned int kfifo_out_peek(struct kfifo *fifo,
*/
static inline bool kfifo_initialized(struct kfifo *fifo)
{
- return fifo->buffer != 0;
+ return fifo->buffer != NULL;
}
/**
diff --git a/kernel/kfifo.c b/kernel/kfifo.c
index 3b00bf8..6d58e1a 100644
--- a/kernel/kfifo.c
+++ b/kernel/kfifo.c
@@ -80,7 +80,7 @@ int kfifo_alloc(struct kfifo *fifo, unsigned int size, gfp_t gfp_mask)
buffer = kmalloc(size, gfp_mask);
if (!buffer) {
- _kfifo_init(fifo, 0, 0);
+ _kfifo_init(fifo, NULL, 0);
return -ENOMEM;
}
--
1.6.5.7
^ permalink raw reply related
* [PATCH 2/3] USB: FHCI: Fix build after kfifo rework
From: Anton Vorontsov @ 2010-01-27 14:09 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-usb, Stefani Seibold, Greg Kroah-Hartman, linux-kernel,
linuxppc-dev
In-Reply-To: <20100127140809.GA27906@oksana.dev.rtsoft.ru>
After kfifo rework FHCI fails to build:
CC drivers/usb/host/fhci-tds.o
drivers/usb/host/fhci-tds.c: In function 'fhci_ep0_free':
drivers/usb/host/fhci-tds.c:108: error: used struct type value where scalar is required
drivers/usb/host/fhci-tds.c:118: error: used struct type value where scalar is required
drivers/usb/host/fhci-tds.c:128: error: used struct type value where scalar is required
This is because kfifos are no longer pointers in the ep struct.
So, instead of checking the pointers, we should now check if kfifo
is initialized.
Reported-by: Josh Boyer <jwboyer@gmail.com>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/usb/host/fhci-tds.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/fhci-tds.c b/drivers/usb/host/fhci-tds.c
index d224ab4..e123289 100644
--- a/drivers/usb/host/fhci-tds.c
+++ b/drivers/usb/host/fhci-tds.c
@@ -105,7 +105,7 @@ void fhci_ep0_free(struct fhci_usb *usb)
if (ep->td_base)
cpm_muram_free(cpm_muram_offset(ep->td_base));
- if (ep->conf_frame_Q) {
+ if (kfifo_initialized(&ep->conf_frame_Q)) {
size = cq_howmany(&ep->conf_frame_Q);
for (; size; size--) {
struct packet *pkt = cq_get(&ep->conf_frame_Q);
@@ -115,7 +115,7 @@ void fhci_ep0_free(struct fhci_usb *usb)
cq_delete(&ep->conf_frame_Q);
}
- if (ep->empty_frame_Q) {
+ if (kfifo_initialized(&ep->empty_frame_Q)) {
size = cq_howmany(&ep->empty_frame_Q);
for (; size; size--) {
struct packet *pkt = cq_get(&ep->empty_frame_Q);
@@ -125,7 +125,7 @@ void fhci_ep0_free(struct fhci_usb *usb)
cq_delete(&ep->empty_frame_Q);
}
- if (ep->dummy_packets_Q) {
+ if (kfifo_initialized(&ep->dummy_packets_Q)) {
size = cq_howmany(&ep->dummy_packets_Q);
for (; size; size--) {
u8 *buff = cq_get(&ep->dummy_packets_Q);
--
1.6.5.7
^ permalink raw reply related
* [PATCH 1/3] kfifo: Make kfifo_initialized work after kfifo_free
From: Anton Vorontsov @ 2010-01-27 14:09 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-usb, Stefani Seibold, Greg Kroah-Hartman, linux-kernel,
linuxppc-dev
In-Reply-To: <20100127140809.GA27906@oksana.dev.rtsoft.ru>
After kfifo rework it's no longer possible to reliably know if kfifo is
usable, since after kfifo_free(), kfifo_initialized() would still return
true. The correct behaviour is needed for at least FHCI USB driver.
This patch fixes the issue by resetting the kfifo to zero values (the
same approach is used in kfifo_alloc() if allocation failed).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
kernel/kfifo.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kernel/kfifo.c b/kernel/kfifo.c
index 32c5c15..3b00bf8 100644
--- a/kernel/kfifo.c
+++ b/kernel/kfifo.c
@@ -97,6 +97,7 @@ EXPORT_SYMBOL(kfifo_alloc);
void kfifo_free(struct kfifo *fifo)
{
kfree(fifo->buffer);
+ _kfifo_init(fifo, NULL, 0);
}
EXPORT_SYMBOL(kfifo_free);
--
1.6.5.7
^ permalink raw reply related
* Re: [PATCH 5/8 v2] powerpc/mpc5121: add USB host support
From: Jan Andersson @ 2010-01-27 12:36 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: wd, dzu, linux-usb, linuxppc-dev, Bruce Schmid
In-Reply-To: <1264594052-20317-6-git-send-email-agust@denx.de>
Anatolij Gustschin wrote:
> @@ -259,6 +305,11 @@ static int ehci_fsl_setup(struct usb_hcd *hcd)
> {
> struct ehci_hcd *ehci = hcd_to_ehci(hcd);
> int retval;
> + struct fsl_usb2_platform_data *pdata;
> +
> + pdata = hcd->self.controller->platform_data;
> + ehci->big_endian_desc = pdata->big_endian_desc;
> + ehci->big_endian_mmio = pdata->big_endian_mmio;
I recently posted some questions to linux-usb@vger about big_endian_mmio
and the definition of the HC_LENGTH and HC_VERSION macros. The thread
can be found here: http://marc.info/?l=linux-usb&m=126441448626924&w=2
The EHCI specification defines the CAPLENGTH register as an 8-bit
register at byte offset 0 and HCIVERSION as a 16-bit register at byte
offset 2. Performing a 32-bit read on a big endian system should
therefore results in the following organisation (MSB .. LSB):
CAPLENGTH : RESERVED : HCIVERSION
The macros for reading CAPLENGTH and HCIVERSION (defined in
include/linux/usb/ehci-def.h) look like:
#define HC_LENGTH(p) (((p)>>00)&0x00ff) /* bits 7:0 */
#define HC_VERSION(p) (((p)>>16)&0xffff) /* bits 31:16 */
That is, they select the registers as they were organized within the
word according to little endian. Is this not a problem for your
controller/driver?
Best regards,
Jan
^ permalink raw reply
* [PATCH 0/3 for 2.6.33] Some fixes for kfifo and FHCI
From: Anton Vorontsov @ 2010-01-27 14:08 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-usb, Stefani Seibold, Greg Kroah-Hartman, linux-kernel,
linuxppc-dev
Hi all,
FHCI no longer builds after kfifo rework, this patch set is
used to fix the issues.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ 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