* Re: [PATCH] commit e8f605cd71aa09a8f8b73f410a15d2a46022a60e
From: Grant Likely @ 2007-10-18 1:26 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20071017234100.7729.85901.stgit@trillian.cg.shawcable.net>
On 10/17/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> mpc8349emitx(gp): add UHCI and USB storage support
Oops, sorry about the subject line; I kind of messed that up in stgit.
g.
>
> USB support for the 8349itx got added a while back; but the defconfig
> never got updated. This patch adds the appropriate USB config options
> to defconfig
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> CC: Scott Wood <scottwood@freescale.com>
> CC: Kumar Gala <galak@kernel.crashing.org>
> CC: Timur Tabi <timur@freescale.com>
> ---
>
> arch/powerpc/configs/mpc834x_itx_defconfig | 2 -
> arch/powerpc/configs/mpc834x_itxgp_defconfig | 88 ++++++++++++++++++++++++++
> 2 files changed, 88 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/configs/mpc834x_itx_defconfig b/arch/powerpc/configs/mpc834x_itx_defconfig
> index eb28dd8..ba512d1 100644
> --- a/arch/powerpc/configs/mpc834x_itx_defconfig
> +++ b/arch/powerpc/configs/mpc834x_itx_defconfig
> @@ -867,7 +867,7 @@ CONFIG_USB_EHCI_ROOT_HUB_TT=y
> CONFIG_USB_EHCI_FSL=y
> # CONFIG_USB_ISP116X_HCD is not set
> # CONFIG_USB_OHCI_HCD is not set
> -# CONFIG_USB_UHCI_HCD is not set
> +CONFIG_USB_UHCI_HCD=y
> # CONFIG_USB_SL811_HCD is not set
> # CONFIG_USB_R8A66597_HCD is not set
>
> diff --git a/arch/powerpc/configs/mpc834x_itxgp_defconfig b/arch/powerpc/configs/mpc834x_itxgp_defconfig
> index 22b9546..9faa948 100644
> --- a/arch/powerpc/configs/mpc834x_itxgp_defconfig
> +++ b/arch/powerpc/configs/mpc834x_itxgp_defconfig
> @@ -760,15 +760,101 @@ CONFIG_USB_SUPPORT=y
> CONFIG_USB_ARCH_HAS_HCD=y
> CONFIG_USB_ARCH_HAS_OHCI=y
> CONFIG_USB_ARCH_HAS_EHCI=y
> -# CONFIG_USB is not set
> +CONFIG_USB=y
> +# CONFIG_USB_DEBUG is not set
> +
> +#
> +# Miscellaneous USB options
> +#
> +# CONFIG_USB_DEVICEFS is not set
> +CONFIG_USB_DEVICE_CLASS=y
> +# CONFIG_USB_DYNAMIC_MINORS is not set
> +# CONFIG_USB_OTG is not set
> +
> +#
> +# USB Host Controller Drivers
> +#
> +CONFIG_USB_EHCI_HCD=y
> +# CONFIG_USB_EHCI_SPLIT_ISO is not set
> CONFIG_USB_EHCI_ROOT_HUB_TT=y
> +# CONFIG_USB_EHCI_TT_NEWSCHED is not set
> CONFIG_USB_EHCI_FSL=y
> +# CONFIG_USB_ISP116X_HCD is not set
> +# CONFIG_USB_OHCI_HCD is not set
> +CONFIG_USB_UHCI_HCD=y
> +# CONFIG_USB_SL811_HCD is not set
> +# CONFIG_USB_R8A66597_HCD is not set
> +
> +#
> +# USB Device Class drivers
> +#
> +# CONFIG_USB_ACM is not set
> +# CONFIG_USB_PRINTER is not set
>
> #
> # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
> #
>
> #
> +# may also be needed; see USB_STORAGE Help for more information
> +#
> +CONFIG_USB_STORAGE=y
> +# CONFIG_USB_STORAGE_DEBUG is not set
> +# CONFIG_USB_STORAGE_DATAFAB is not set
> +# CONFIG_USB_STORAGE_FREECOM is not set
> +# CONFIG_USB_STORAGE_DPCM is not set
> +# CONFIG_USB_STORAGE_USBAT is not set
> +# CONFIG_USB_STORAGE_SDDR09 is not set
> +# CONFIG_USB_STORAGE_SDDR55 is not set
> +# CONFIG_USB_STORAGE_JUMPSHOT is not set
> +# CONFIG_USB_STORAGE_ALAUDA is not set
> +# CONFIG_USB_STORAGE_KARMA is not set
> +# CONFIG_USB_LIBUSUAL is not set
> +
> +#
> +# USB Imaging devices
> +#
> +# CONFIG_USB_MDC800 is not set
> +# CONFIG_USB_MICROTEK is not set
> +CONFIG_USB_MON=y
> +
> +#
> +# USB port drivers
> +#
> +
> +#
> +# USB Serial Converter support
> +#
> +# CONFIG_USB_SERIAL is not set
> +
> +#
> +# USB Miscellaneous drivers
> +#
> +# CONFIG_USB_EMI62 is not set
> +# CONFIG_USB_EMI26 is not set
> +# CONFIG_USB_ADUTUX is not set
> +# CONFIG_USB_AUERSWALD is not set
> +# CONFIG_USB_RIO500 is not set
> +# CONFIG_USB_LEGOTOWER is not set
> +# CONFIG_USB_LCD is not set
> +# CONFIG_USB_BERRY_CHARGE is not set
> +# CONFIG_USB_LED is not set
> +# CONFIG_USB_CYPRESS_CY7C63 is not set
> +# CONFIG_USB_CYTHERM is not set
> +# CONFIG_USB_PHIDGET is not set
> +# CONFIG_USB_IDMOUSE is not set
> +# CONFIG_USB_FTDI_ELAN is not set
> +# CONFIG_USB_APPLEDISPLAY is not set
> +# CONFIG_USB_SISUSBVGA is not set
> +# CONFIG_USB_LD is not set
> +# CONFIG_USB_TRANCEVIBRATOR is not set
> +# CONFIG_USB_IOWARRIOR is not set
> +
> +#
> +# USB DSL modem support
> +#
> +
> +#
> # USB Gadget Support
> #
> # CONFIG_USB_GADGET is not set
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] synchronize_irq needs a barrier
From: Benjamin Herrenschmidt @ 2007-10-18 1:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, akpm, Linux Kernel list
synchronize_irq needs at the very least a compiler barrier and a
read barrier on SMP, but there are enough cases around where a
write barrier is also needed and it's not a hot path so I prefer
using a full smp_mb() here.
It will degrade to a compiler barrier on !SMP.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-work/kernel/irq/manage.c
===================================================================
--- linux-work.orig/kernel/irq/manage.c 2007-10-18 11:22:16.000000000 +1000
+++ linux-work/kernel/irq/manage.c 2007-10-18 11:22:20.000000000 +1000
@@ -33,6 +33,7 @@ void synchronize_irq(unsigned int irq)
if (irq >= NR_IRQS)
return;
+ smp_mb();
while (desc->status & IRQ_INPROGRESS)
cpu_relax();
}
^ permalink raw reply
* Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: Michael Ellerman @ 2007-10-18 1:23 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, sfr, paulus, linuxppc-dev
In-Reply-To: <20071017.042345.108116673.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
On Wed, 2007-10-17 at 04:23 -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 17 Oct 2007 04:22:29 -0700 (PDT)
>
> > From: Michael Ellerman <michael@ellerman.id.au>
> > Date: Wed, 17 Oct 2007 17:12:27 +1000 (EST)
> >
> > > Use of_get_pci_dev_node() in axon_msi.c. Switch to including <linux/of.h>
> > > so we get the prototype.
> > >
> > > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> >
> > I find it ironic that you add of_get_pci_dev_node() as a function
> > which gets the node and grabs a reference to it, and then the very
> > first usage you make of it doesn't drop the reference at all.
>
> Ignore this poor attempt at humor, I misread your patch :)
Well it _would_ have been funny :)
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Add napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-18 1:19 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Roland Dreier, David S. Miller, Jeff Garzik,
linuxppc-dev list
In-Reply-To: <1192658654.6783.43.camel@pasglop>
> This implements a low level __napi_synchronize() function to acheive
> that. The underscores are to emphasis the low level aspect of it and
> to discourage driver writers who don't know what they are doing to
> use it (to please DaveM :-)
And I forgot to remove that bit from the description... as pointed out
by Josh. Grrr...
Ben.
^ permalink raw reply
* Re: [PATCH] net: Add napi_sycnhronize() to sync with napi poll
From: Josh Boyer @ 2007-10-18 1:02 UTC (permalink / raw)
To: benh
Cc: Jeff Garzik, netdev, Roland Dreier, linuxppc-dev list,
Stephen Hemminger, David S. Miller
In-Reply-To: <1192658654.6783.43.camel@pasglop>
On Thu, 2007-10-18 at 08:04 +1000, Benjamin Herrenschmidt wrote:
> net: Add __napi_synchronize() to sync with napi poll
>
> The EMAC driver which needs to handle multiple devices with one
> NAPI instance implements its own per-channel disable bit. However,
> when setting such a bit, it needs to synchronize with the poller
> (that is make sure that any pending poller instance has completed,
> or is started late enough to see that disable bit).
>
> This implements a low level __napi_synchronize() function to acheive
> that. The underscores are to emphasis the low level aspect of it and
> to discourage driver writers who don't know what they are doing to
> use it (to please DaveM :-)
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Ok, trying again, leaving the actual patch below. In the above patch
description, you still call it __napi_synchronize. In the patch below,
it's napi_syncronize.
I was just trying to point out to whomever commits this patch that the
actual description should probably be fixed.
> ---
>
> Back to msleep() since it fits my need well and that's what
> you used as well. Note that the smp_mb() will turn into barrier()
> on non-SMP.
>
> I'll send a separate patch to fix EMAC to use the non __ version.
>
> Index: linux-work/include/linux/netdevice.h
> ===================================================================
> --- linux-work.orig/include/linux/netdevice.h 2007-10-17 13:31:32.000000000 +1000
> +++ linux-work/include/linux/netdevice.h 2007-10-18 08:01:05.000000000 +1000
> @@ -394,6 +394,23 @@ static inline void napi_disable(struct n
> }
>
> /**
> + * napi_synchronize - synchronize with a concurrent poll
> + * @n: napi context
> + *
> + * Synchronizes with a concurrent poll. Not to be used in normal
> + * drivers, mostly useful if you end up with multiple interfaces
> + * on one NAPI instance. This must be called from task context.
> + */
> +static inline void napi_synchronize(struct napi_struct *n)
> +{
> + smp_mb();
> +#ifdef CONFIG_SMP
> + while (test_bit(NAPI_STATE_SCHED, &n->state))
> + msleep(1);
> +#endif /* CONFIG_SMP */
> +}
> +
> +/**
> * napi_enable - enable NAPI scheduling
> * @n: napi context
> *
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: Kumar Gala @ 2007-10-18 0:54 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev list, Stefan Roese
In-Reply-To: <1192646394.4026.70.camel@shinybook.infradead.org>
On Oct 17, 2007, at 1:39 PM, David Woodhouse wrote:
>
> On Mon, 2007-10-15 at 18:07 -0500, Kumar Gala wrote:
>> Guys,
>>
>> I was wondering if you cared about the following boards existing in
>> arch/powerpc:
>>
>> * STX GP3
>> * TQM 85xx
>> * SBC 8560
>>
>> I'm told WR doesn't care about the SBC 8560, so I'll see if David
>> does.
>
> Well, I found an sbc8560 in the boot of my car the other day and I
> suppose it shouldn't take much -- so I might as well take a look, next
> time I'm home.
This really cracked me up. I have to ask what the sbc8560 was doing
in the boot of your car?
- k
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Paul Mackerras @ 2007-10-18 0:51 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <47161C38.2070305@ru.mvista.com>
Sergei Shtylyov writes:
> > Tony started from an earlier patch by John Stultz, not from your
> > patches.
>
> Well, that I can believe, yet the clockevents patch has traces of my
> former work, and looking at read_persisitent_time() it looks suspiciously
> close to my version too...
There is basically only one reasonably way to do a lot of this stuff.
> > The main reason your patches were rejected were that you completely
> > broke the VDSO and the deterministic time accounting, and made no
>
> That's just not true!
> They didn't broke vDSO (to be precise it was John's patch that broke it),
> they just removed the vDSO code known to already be broken by -rt patch for
> several months by then. And they didn't broke determinictic accounting --
> they just made two things mutually exclusive. I haven't yet seen how the
> patches that were preferred dealt with it at all.
OK. My requirement was that the clocksource/clockevent stuff and the
VDSO were both functional. Your patch didn't meet that requirement.
> Really? IMO, the harware does keep a constant interrupt rate better than
> software.
Well, if you have actual numbers to back that up, show them to us.
I don't believe you would be able to measure any difference, and so I
prefer the simplicity of only implementing the one-shot mode.
> > Because you broke important features
>
> That is *not true*.
> And nobody had interest to fix them for months (quite strange if they're
> so important) while I had neither time nor interest to deal with them anymore
> having written the code that *did work*, and not only for me.
Well, this is the difference between having a hack that works for you,
and having something that can go upstream into mainline.
Anyway, this discussion doesn't seem to be going anywhere. If there
are changes you want made, or any other specific concrete action you
want anyone to do, say so. Otherwise stop whinging.
Paul.
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Paul Mackerras @ 2007-10-18 0:36 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <47161D79.6000003@ru.mvista.com>
Sergei Shtylyov writes:
> BTW, while fixing that for classic PPC, but you've broke it for 40x / book
> E CPU which interrupt at 0. Congratulations. :-)
What problem do you see arising from this?
Paul.
^ permalink raw reply
* Re: [PATCH 04/15] [POWERPC] CM5200 DTS
From: David Gibson @ 2007-10-18 0:22 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4715FE6C.2070201@semihalf.com>
On Wed, Oct 17, 2007 at 02:22:04PM +0200, Marian Balakowicz wrote:
> David Gibson wrote:
> > [snip]
> >> + flash@c000000 {
> >> + device_type = "rom";
> >> + compatible = "direct-mapped";
> >> + reg = <0c000000 02000000>;
> >> + probe-type = "CFI";
> >> + bank-width = <2>;
> >> + partitions = <00000000 00060000
> >> + 00060000 00020000
> >> + 00080000 00020000
> >> + 000a0000 00020000
> >> + 000c0000 00200000
> >> + 002c0000 01b40000
> >> + 01e00000 00200000>;
> >> + partition-names = "uboot\0env\0redund_env\0dtb\0kernel\0rootfs\0config";
> >> + };
> >
> > First, this is the old flash binding, please use the new one.
>
> Ok.
>
> > Second, is the flash really part of the SoC?
>
> Not directly, it is attached to LocalPlus Bus Controller, which is
> part of the SoC. And the soc@ is currently the only recognized of bus
> for mpc5200, so if we want to move it to some other place new bindings
> will need to be defined for lpc (LocalPlus Controller) bus. But I am
> not quite sure where this should be attached. Bus is under LPC which
> is a part of the SoC, but on the other hand Soc address range covers
> only device control registers not the address space LPC may handle
> (that may be varied). Any ideas?
The bus bridge has to be there. Is this something similar to the
"localbus" / "chipselect" bus controllers that a whole bunch of the
Freescale SoCs have? Because the bridged addresses don't lie in the
IMMR, althoug the control registers do, the current convention is to
make the localbus node a sibling of /soc, even though it is really
part of the SoC (/soc would perhaps be better called /immr, but /soc
is established now). This approach is imperfect, but so are most of
the other compromises we could make.
Incidentally LPC is a pretty bad abbreviation, since LPC more
frequently refers to the Low Pin Count connections that frequently
appear on south bridges or superIO chips.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] fix EMAC driver for proper napi_synchronize API
From: Jeff Garzik @ 2007-10-18 0:21 UTC (permalink / raw)
To: benh
Cc: netdev, Roland Dreier, Stephen Hemminger, David S. Miller,
linuxppc-dev list
In-Reply-To: <1192662843.6783.48.camel@pasglop>
Benjamin Herrenschmidt wrote:
> The EMAC driver "fix" was merged by mistake before the dust had settled on
> the new napi synchronize interface (and before it got merged). The final
> version of that function is spelled without underscores.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
applied
^ permalink raw reply
* Re: [PATCH][NET] gianfar: fix obviously wrong #ifdef CONFIG_GFAR_NAPI placement
From: Jeff Garzik @ 2007-10-18 0:21 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: netdev, linux-kernel, linuxppc-dev, paulus, leoli
In-Reply-To: <20071017195746.GA15592@localhost.localdomain>
Anton Vorontsov wrote:
> Erroneous #ifdef introduced by 293c8513398657f6263fcdb03c87f2760cf61be4
> causing NAPI-less ethernet malfunctioning.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
applied
^ permalink raw reply
* Re: [PATCH] fs_enet: Update for API changes
From: Jeff Garzik @ 2007-10-18 0:21 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071017174243.GA4462@loki.buserror.net>
Scott Wood wrote:
> This driver was recently broken by several changes for which this
> driver was not (or was improperly) updated:
>
> 1. SET_MODULE_OWNER() was removed.
> 2. netif_napi_add() was only being called when building with
> the old CPM binding.
> 3. The received/budget test was backwards.
> 4. to_net_dev() was wrong -- the device struct embedded in
> the net_device struct is not the same as the of_platform
> device in the private struct.
> 5. napi_disable/napi_enable was being called even when napi
> was not being used.
>
> These changes have been fixed, and napi is now on by default.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
applied
^ permalink raw reply
* Re: 2.6.23-mm1 - build failure with advansys
From: Paul Mackerras @ 2007-10-18 0:07 UTC (permalink / raw)
To: Andrew Morton
Cc: Matthew Wilcox, linuxppc-dev, linux-kernel, Kamalesh Babulal
In-Reply-To: <20071012235242.9d7daf05.akpm@linux-foundation.org>
Andrew Morton writes:
> On Sat, 13 Oct 2007 10:14:22 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > The functions virt_to_bus and bus_to_virt are begin defined between ifdef CONFIG_PPC32
> > but when i compile allyesconfig with ppc64 box,i get this error. This patch removes the
> > ifdef.
Which is totally bogus, because virt_to_bus/bus_to_virt only work on
systems without an IOMMU. Most if not all ppc64 systems have one or
more IOMMUs. This patch is nacked.
The correct fix is to make advansys depend on CONFIG_VIRT_TO_BUS, or
alternatively fix advansys.c properly by making it use the interfaces
described in Documentation/DMA-mapping.txt (or the equivalent scsi
helpers).
> Please copy the powerpc developers on powerpc patches.
Definitely.
Paul.
^ permalink raw reply
* Re: [PATCH] net: Add napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-17 23:59 UTC (permalink / raw)
To: Josh Boyer
Cc: Jeff Garzik, netdev, Roland Dreier, linuxppc-dev list,
Stephen Hemminger, David S. Miller
In-Reply-To: <1192664183.13993.30.camel@localhost.localdomain>
On Wed, 2007-10-17 at 18:36 -0500, Josh Boyer wrote:
> On Thu, 2007-10-18 at 08:04 +1000, Benjamin Herrenschmidt wrote:
> > net: Add __napi_synchronize() to sync with napi poll
> >
> > The EMAC driver which needs to handle multiple devices with one
> > NAPI instance implements its own per-channel disable bit. However,
> > when setting such a bit, it needs to synchronize with the poller
> > (that is make sure that any pending poller instance has completed,
> > or is started late enough to see that disable bit).
> >
> > This implements a low level __napi_synchronize() function to acheive
> > that. The underscores are to emphasis the low level aspect of it and
> > to discourage driver writers who don't know what they are doing to
> > use it (to please DaveM :-)
>
> Erm.. your commit log calls it __napi_synchronize still.
The commit is a mistake, I sent a patch to rename it, or did I miss
something ?
Ben.
^ permalink raw reply
* Re: [PATCH] net: Add napi_sycnhronize() to sync with napi poll
From: Josh Boyer @ 2007-10-17 23:36 UTC (permalink / raw)
To: benh
Cc: Jeff Garzik, netdev, Roland Dreier, linuxppc-dev list,
Stephen Hemminger, David S. Miller
In-Reply-To: <1192658654.6783.43.camel@pasglop>
On Thu, 2007-10-18 at 08:04 +1000, Benjamin Herrenschmidt wrote:
> net: Add __napi_synchronize() to sync with napi poll
>
> The EMAC driver which needs to handle multiple devices with one
> NAPI instance implements its own per-channel disable bit. However,
> when setting such a bit, it needs to synchronize with the poller
> (that is make sure that any pending poller instance has completed,
> or is started late enough to see that disable bit).
>
> This implements a low level __napi_synchronize() function to acheive
> that. The underscores are to emphasis the low level aspect of it and
> to discourage driver writers who don't know what they are doing to
> use it (to please DaveM :-)
Erm.. your commit log calls it __napi_synchronize still.
josh
^ permalink raw reply
* [PATCH] commit e8f605cd71aa09a8f8b73f410a15d2a46022a60e
From: Grant Likely @ 2007-10-17 23:41 UTC (permalink / raw)
To: galak, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
mpc8349emitx(gp): add UHCI and USB storage support
USB support for the 8349itx got added a while back; but the defconfig
never got updated. This patch adds the appropriate USB config options
to defconfig
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
CC: Scott Wood <scottwood@freescale.com>
CC: Kumar Gala <galak@kernel.crashing.org>
CC: Timur Tabi <timur@freescale.com>
---
arch/powerpc/configs/mpc834x_itx_defconfig | 2 -
arch/powerpc/configs/mpc834x_itxgp_defconfig | 88 ++++++++++++++++++++++++++
2 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/configs/mpc834x_itx_defconfig b/arch/powerpc/configs/mpc834x_itx_defconfig
index eb28dd8..ba512d1 100644
--- a/arch/powerpc/configs/mpc834x_itx_defconfig
+++ b/arch/powerpc/configs/mpc834x_itx_defconfig
@@ -867,7 +867,7 @@ CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_FSL=y
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
-# CONFIG_USB_UHCI_HCD is not set
+CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
diff --git a/arch/powerpc/configs/mpc834x_itxgp_defconfig b/arch/powerpc/configs/mpc834x_itxgp_defconfig
index 22b9546..9faa948 100644
--- a/arch/powerpc/configs/mpc834x_itxgp_defconfig
+++ b/arch/powerpc/configs/mpc834x_itxgp_defconfig
@@ -760,15 +760,101 @@ CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
-# CONFIG_USB is not set
+CONFIG_USB=y
+# CONFIG_USB_DEBUG is not set
+
+#
+# Miscellaneous USB options
+#
+# CONFIG_USB_DEVICEFS is not set
+CONFIG_USB_DEVICE_CLASS=y
+# CONFIG_USB_DYNAMIC_MINORS is not set
+# CONFIG_USB_OTG is not set
+
+#
+# USB Host Controller Drivers
+#
+CONFIG_USB_EHCI_HCD=y
+# CONFIG_USB_EHCI_SPLIT_ISO is not set
CONFIG_USB_EHCI_ROOT_HUB_TT=y
+# CONFIG_USB_EHCI_TT_NEWSCHED is not set
CONFIG_USB_EHCI_FSL=y
+# CONFIG_USB_ISP116X_HCD is not set
+# CONFIG_USB_OHCI_HCD is not set
+CONFIG_USB_UHCI_HCD=y
+# CONFIG_USB_SL811_HCD is not set
+# CONFIG_USB_R8A66597_HCD is not set
+
+#
+# USB Device Class drivers
+#
+# CONFIG_USB_ACM is not set
+# CONFIG_USB_PRINTER is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
+# may also be needed; see USB_STORAGE Help for more information
+#
+CONFIG_USB_STORAGE=y
+# CONFIG_USB_STORAGE_DEBUG is not set
+# CONFIG_USB_STORAGE_DATAFAB is not set
+# CONFIG_USB_STORAGE_FREECOM is not set
+# CONFIG_USB_STORAGE_DPCM is not set
+# CONFIG_USB_STORAGE_USBAT is not set
+# CONFIG_USB_STORAGE_SDDR09 is not set
+# CONFIG_USB_STORAGE_SDDR55 is not set
+# CONFIG_USB_STORAGE_JUMPSHOT is not set
+# CONFIG_USB_STORAGE_ALAUDA is not set
+# CONFIG_USB_STORAGE_KARMA is not set
+# CONFIG_USB_LIBUSUAL is not set
+
+#
+# USB Imaging devices
+#
+# CONFIG_USB_MDC800 is not set
+# CONFIG_USB_MICROTEK is not set
+CONFIG_USB_MON=y
+
+#
+# USB port drivers
+#
+
+#
+# USB Serial Converter support
+#
+# CONFIG_USB_SERIAL is not set
+
+#
+# USB Miscellaneous drivers
+#
+# CONFIG_USB_EMI62 is not set
+# CONFIG_USB_EMI26 is not set
+# CONFIG_USB_ADUTUX is not set
+# CONFIG_USB_AUERSWALD is not set
+# CONFIG_USB_RIO500 is not set
+# CONFIG_USB_LEGOTOWER is not set
+# CONFIG_USB_LCD is not set
+# CONFIG_USB_BERRY_CHARGE is not set
+# CONFIG_USB_LED is not set
+# CONFIG_USB_CYPRESS_CY7C63 is not set
+# CONFIG_USB_CYTHERM is not set
+# CONFIG_USB_PHIDGET is not set
+# CONFIG_USB_IDMOUSE is not set
+# CONFIG_USB_FTDI_ELAN is not set
+# CONFIG_USB_APPLEDISPLAY is not set
+# CONFIG_USB_SISUSBVGA is not set
+# CONFIG_USB_LD is not set
+# CONFIG_USB_TRANCEVIBRATOR is not set
+# CONFIG_USB_IOWARRIOR is not set
+
+#
+# USB DSL modem support
+#
+
+#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
^ permalink raw reply related
* [PATCH] fix EMAC driver for proper napi_synchronize API
From: Benjamin Herrenschmidt @ 2007-10-17 23:14 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Roland Dreier, David S. Miller, Jeff Garzik,
linuxppc-dev list
In-Reply-To: <20071017083107.6a1b1bd3@freepuppy.rosehill>
The EMAC driver "fix" was merged by mistake before the dust had settled on
the new napi synchronize interface (and before it got merged). The final
version of that function is spelled without underscores.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-work/drivers/net/ibm_newemac/mal.c
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/mal.c 2007-10-18 08:02:22.000000000 +1000
+++ linux-work/drivers/net/ibm_newemac/mal.c 2007-10-18 08:02:24.000000000 +1000
@@ -322,7 +322,7 @@ void mal_poll_disable(struct mal_instanc
msleep(1);
/* Synchronize with the MAL NAPI poller */
- __napi_synchronize(&mal->napi);
+ napi_synchronize(&mal->napi);
}
void mal_poll_enable(struct mal_instance *mal, struct mal_commac *commac)
^ permalink raw reply
* [PATCH] Move _rtc_time() routines under CONFIG_ADB_CUDA
From: Badari Pulavarty @ 2007-10-17 23:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: lkml
Fix to clean up compile warnings (against 2.6.23-git12)
Thanks,
Badari
to_rtc_time() and from_rtc_time() seems to be used only if CONFIG_ADB_CUDA
defined. Moving them under that ifdef.
arch/powerpc/platforms/powermac/time.c:88: warning: `to_rtc_time' defined but not used
arch/powerpc/platforms/powermac/time.c:95: warning: `from_rtc_time' defined but not used
Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
---
arch/powerpc/platforms/powermac/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23/arch/powerpc/platforms/powermac/time.c
===================================================================
--- linux-2.6.23.orig/arch/powerpc/platforms/powermac/time.c 2007-10-09 13:31:38.000000000 -0700
+++ linux-2.6.23/arch/powerpc/platforms/powermac/time.c 2007-10-17 15:59:56.000000000 -0700
@@ -84,6 +84,7 @@ long __init pmac_time_init(void)
return delta;
}
+#ifdef CONFIG_ADB_CUDA
static void to_rtc_time(unsigned long now, struct rtc_time *tm)
{
to_tm(now, tm);
@@ -97,7 +98,6 @@ static unsigned long from_rtc_time(struc
tm->tm_hour, tm->tm_min, tm->tm_sec);
}
-#ifdef CONFIG_ADB_CUDA
static unsigned long cuda_get_time(void)
{
struct adb_request req;
^ permalink raw reply
* Re: [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: Linas Vepstas @ 2007-10-17 23:04 UTC (permalink / raw)
To: Michael Ellerman
Cc: sparclinux, Stephen Rothwell, Paul Mackerras, David S. Miller,
linuxppc-dev
In-Reply-To: <dadd2b9540369b9e2c6773b2a60021dadafa58e2.1192605144.git.michael@ellerman.id.au>
On Wed, Oct 17, 2007 at 05:12:27PM +1000, Michael Ellerman wrote:
> +struct device_node *of_get_pci_dev_node(struct pci_dev *pdev)
> +{
> + return of_node_get(pci_device_to_OF_node(pdev));
> +}
[...]
> - dn = of_node_get(pci_device_to_OF_node(dev));
> + dn = of_get_pci_dev_node(dev);
Is this really useful or wise?
As a matter of personal taste, I find stuff like this clutters
and confuses my mind. I go to read new code, and I run across some
routine I haven't heard of before ... e.g. of_get_pci_dev_node(),
so now I have to look it up to see what it does. A few minutes later,
I realize that its just a pair of old freinds (of_node_get and
pci_device_to_OF_node) and so now I have to make mental room for it.
Tommorrow, or 3 days later, I'm again looking at of_get_pci_dev_node()
and I'm thinking "gee what did that thing do again??"
I don't much like this style, and I've been known to submit
patches that remove stuff like this ...
--linas
^ permalink raw reply
* Re: [PATCH] fs_enet: Update for API changes
From: Vitaly Bordug @ 2007-10-17 22:40 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071017174243.GA4462@loki.buserror.net>
Hello Scott,
On Wed, 17 Oct 2007 12:42:43 -0500
Scott Wood wrote:
> This driver was recently broken by several changes for which this
> driver was not (or was improperly) updated:
>
> 1. SET_MODULE_OWNER() was removed.
> 2. netif_napi_add() was only being called when building with
> the old CPM binding.
> 3. The received/budget test was backwards.
> 4. to_net_dev() was wrong -- the device struct embedded in
> the net_device struct is not the same as the of_platform
> device in the private struct.
> 5. napi_disable/napi_enable was being called even when napi
> was not being used.
>
Good cleanup, thanks!
Jeff: this is important fix, and should be applied if possible.
> These changes have been fixed, and napi is now on by default.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: Vitaly Bordug <vitb@kernel.crashing.org>
> ---
> drivers/net/fs_enet/fs_enet-main.c | 28 ++++++++++++++++------------
> drivers/net/fs_enet/fs_enet.h | 1 +
> 2 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
> index 04c6fae..f2a4d39 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -88,7 +88,7 @@ static void skb_align(struct sk_buff *skb, int align)
> static int fs_enet_rx_napi(struct napi_struct *napi, int budget)
> {
> struct fs_enet_private *fep = container_of(napi, struct fs_enet_private, napi);
> - struct net_device *dev = to_net_dev(fep->dev);
> + struct net_device *dev = fep->ndev;
> const struct fs_platform_info *fpi = fep->fpi;
> cbd_t __iomem *bdp;
> struct sk_buff *skb, *skbn, *skbt;
> @@ -217,7 +217,7 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int budget)
>
> fep->cur_rx = bdp;
>
> - if (received >= budget) {
> + if (received < budget) {
> /* done */
> netif_rx_complete(dev, napi);
> (*fep->ops->napi_enable_rx)(dev);
> @@ -807,20 +807,23 @@ static int fs_enet_open(struct net_device *dev)
> int r;
> int err;
>
> - napi_enable(&fep->napi);
> + if (fep->fpi->use_napi)
> + napi_enable(&fep->napi);
>
> /* Install our interrupt handler. */
> r = fs_request_irq(dev, fep->interrupt, "fs_enet-mac", fs_enet_interrupt);
> if (r != 0) {
> printk(KERN_ERR DRV_MODULE_NAME
> ": %s Could not allocate FS_ENET IRQ!", dev->name);
> - napi_disable(&fep->napi);
> + if (fep->fpi->use_napi)
> + napi_disable(&fep->napi);
> return -EINVAL;
> }
>
> err = fs_init_phy(dev);
> - if(err) {
> - napi_disable(&fep->napi);
> + if (err) {
> + if (fep->fpi->use_napi)
> + napi_disable(&fep->napi);
> return err;
> }
> phy_start(fep->phydev);
> @@ -1232,7 +1235,7 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
> fpi->rx_ring = 32;
> fpi->tx_ring = 32;
> fpi->rx_copybreak = 240;
> - fpi->use_napi = 0;
> + fpi->use_napi = 1;
> fpi->napi_weight = 17;
>
> ret = find_phy(ofdev->node, fpi);
> @@ -1249,11 +1252,11 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
> goto out_free_fpi;
> }
>
> - SET_MODULE_OWNER(ndev);
> dev_set_drvdata(&ofdev->dev, ndev);
>
> fep = netdev_priv(ndev);
> fep->dev = &ofdev->dev;
> + fep->ndev = ndev;
> fep->fpi = fpi;
> fep->ops = match->data;
>
> @@ -1288,10 +1291,11 @@ static int __devinit fs_enet_probe(struct of_device *ofdev,
> ndev->stop = fs_enet_close;
> ndev->get_stats = fs_enet_get_stats;
> ndev->set_multicast_list = fs_set_multicast_list;
> - if (fpi->use_napi) {
> - ndev->poll = fs_enet_rx_napi;
> - ndev->weight = fpi->napi_weight;
> - }
> +
> + if (fpi->use_napi)
> + netif_napi_add(ndev, &fep->napi, fs_enet_rx_napi,
> + fpi->napi_weight);
> +
> ndev->ethtool_ops = &fs_ethtool_ops;
> ndev->do_ioctl = fs_ioctl;
>
> diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
> index baf6477..c675e29 100644
> --- a/drivers/net/fs_enet/fs_enet.h
> +++ b/drivers/net/fs_enet/fs_enet.h
> @@ -75,6 +75,7 @@ struct phy_info {
> struct fs_enet_private {
> struct napi_struct napi;
> struct device *dev; /* pointer back to the device (must be initialized first) */
> + struct net_device *ndev;
> spinlock_t lock; /* during all ops except TX pckt processing */
> spinlock_t tx_lock; /* during fs_start_xmit and fs_tx */
> struct fs_platform_info *fpi;
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 1/2] qemu platform, v2
From: Rob Landley @ 2007-10-17 23:09 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, Paul Mackerras, Milton Miller, Christoph Hellwig
In-Reply-To: <fa686aa40710171328y195aca9k6ee8a1a5502fcf57@mail.gmail.com>
On Wednesday 17 October 2007 3:28:41 pm Grant Likely wrote:
> > Including .dtbs in the kernel tree has a big practical problem:
> > they're binary, so can't be patch(1)ed, which makes updating them a
> > complete PITA.
I note that kconfig includes the lex/yacc output files (blah.c_shipped) so you
don't have to have lex and yacc installed to run "menuconfig". It _also_
includes the lex/yacc source which is what you patch and rebuild the _shipped
files from when they need to be changed.
> > I'm working on merging dtc into the kernel tree instead.
>
> I'm kind of late to this party; but I have to say I disagree. Most of
> us are doing just fine installing the dtc tool (and mkimage tool for
> that matter). Cloning it in the kernel tree is just asking for
> divergence.
Milton Miller has some patches that make a "PPC qemu target" kernel image
which doesn't include a device tree, and generates a rom image to boot qemu
with which contains a device tree and hands it off to the Linux kernel. If
qemu can merge that rom image in its BIOS collection, this approach would
meet my immediate needs.
> Cheers,
> g.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* [PATCH] net: Add napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-17 22:04 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Roland Dreier, David S. Miller, Jeff Garzik,
linuxppc-dev list
In-Reply-To: <20071017083107.6a1b1bd3@freepuppy.rosehill>
net: Add __napi_synchronize() to sync with napi poll
The EMAC driver which needs to handle multiple devices with one
NAPI instance implements its own per-channel disable bit. However,
when setting such a bit, it needs to synchronize with the poller
(that is make sure that any pending poller instance has completed,
or is started late enough to see that disable bit).
This implements a low level __napi_synchronize() function to acheive
that. The underscores are to emphasis the low level aspect of it and
to discourage driver writers who don't know what they are doing to
use it (to please DaveM :-)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Back to msleep() since it fits my need well and that's what
you used as well. Note that the smp_mb() will turn into barrier()
on non-SMP.
I'll send a separate patch to fix EMAC to use the non __ version.
Index: linux-work/include/linux/netdevice.h
===================================================================
--- linux-work.orig/include/linux/netdevice.h 2007-10-17 13:31:32.000000000 +1000
+++ linux-work/include/linux/netdevice.h 2007-10-18 08:01:05.000000000 +1000
@@ -394,6 +394,23 @@ static inline void napi_disable(struct n
}
/**
+ * napi_synchronize - synchronize with a concurrent poll
+ * @n: napi context
+ *
+ * Synchronizes with a concurrent poll. Not to be used in normal
+ * drivers, mostly useful if you end up with multiple interfaces
+ * on one NAPI instance. This must be called from task context.
+ */
+static inline void napi_synchronize(struct napi_struct *n)
+{
+ smp_mb();
+#ifdef CONFIG_SMP
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ msleep(1);
+#endif /* CONFIG_SMP */
+}
+
+/**
* napi_enable - enable NAPI scheduling
* @n: napi context
*
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-17 21:52 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, Roland Dreier, David S. Miller, Jeff Garzik,
linuxppc-dev list
In-Reply-To: <20071017083107.6a1b1bd3@freepuppy.rosehill>
On Wed, 2007-10-17 at 08:31 -0700, Stephen Hemminger wrote:
> Please don't use double underscore, for this function name. There is no
> reason to not make it a normal API call.
>
> The sky2 fix I am working on will use napi_synchronize as well.
Allright. A compiler barrier in the !SMP case makes sense, but I would
still want an smp_mb() before the test_bit. I think it's a bug in
synchronize_irq not to have it.
Cheers,
Ben.
> --- a/include/linux/netdevice.h 2007-10-16 16:48:20.000000000 -0700
> +++ b/include/linux/netdevice.h 2007-10-17 08:29:55.000000000 -0700
> @@ -407,6 +407,24 @@ static inline void napi_enable(struct na
> clear_bit(NAPI_STATE_SCHED, &n->state);
> }
>
> +#ifdef CONFIG_SMP
> +/**
> + * napi_synchronize - wait until NAPI is not running
> + * @n: napi context
> + *
> + * Wait until NAPI is done being scheduled on this context.
> + * Any outstanding processing completes but
> + * does not disable future activations.
> + */
> +static inline void napi_synchronize(const struct napi_struct *n)
> +{
> + while (test_bit(NAPI_STATE_SCHED, &n->state))
> + msleep(1);
> +}
> +#else
> +# define napi_synchronize(n) barrier()
> +#endif
> +
> /*
> * The DEVICE structure.
> * Actually, this whole structure is a big mistake. It mixes I/O
^ permalink raw reply
* Re: Merge dtc
From: Jon Loeliger @ 2007-10-17 21:51 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras, Timur Tabi, David Gibson
In-Reply-To: <20071017214217.GW4891@austin.ibm.com>
So, like, the other day Linas Vepstas mumbled:
>
> Isn't anyone concerned about the defacto fork-of-source-code that
> this causes?
You betcha. That's why I'm negative on the notion,
but I won't stand in front of _that_ train either.
> Which will be the official version?
The one I am maintaining here on jdl.com.
> How will the code baes be kept in sync?
I heard Gibson volunteer. :-)
jdl
^ permalink raw reply
* Re: Merge dtc
From: Linas Vepstas @ 2007-10-17 21:42 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <47166988.3010606@freescale.com>
On Wed, Oct 17, 2007 at 02:59:04PM -0500, Timur Tabi wrote:
> Kumar Gala wrote:
>
> > Just out of interest who's complaining? We don't include mkimage for
> > u-boot related builds and I haven't seen any gripes related to that.
>
> I think we should include mkimage *and* dtc. But then, I'm not sure how much
> weight my opinion has. :-)
Isn't anyone concerned about the defacto fork-of-source-code that
this causes? Which will be the official version? How will the code
baes be kept in sync?
--linas
^ 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