Re: [OpenWrt-Devel] kernel panic on p54pci insertion on mipsel
On Wednesday 06 August 2008 22:28:32 Tomasz Chmielewski wrote: > Johannes Berg schrieb: > >> Call > >> Trace:[<8018405c>][<8001d2bc>][<8004cc30>][<8004e0dc>][<80002ca4>][<8001c310>][<80001e54>][<80002ca4>][<80125850>][][][] > >> > >> Code: 8ca40150 24020001 afa20010 <8c820078> 00a08021 30420200 1440009f > >> 8cb10160 8c820010 > >> Kernel panic - not syncing: Fatal exception in interrupt > > > > Please remove me from the CC list, at least until you've discovered > > ksymoops. > > Sorry for that. Is this one more helpful? No, you seem to be using the wrong System.map and/or vmlinux image. Read the manpage, please. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Smallest Linux
On Tuesday 14 October 2008 00:13:56 RHS Linux User wrote: > > Hi All, > > Thanks for all your comments so far. > > Of interest, elinux.org has some "real" data about very small > linux versions. > > From what I see it is VERY hard to determine what RAM is really needed > by the kernel??!! > > So any cleanup and shrink effort could be quite a large effort? > > That said, we REALLY need to have available a BARE MINIMUM kernel that > is clearly documented so the MINIMUM requirements to run any sort of linux > can be easily determined. I am NOT planning to become the focal point > person for such an effort, but it is probably worth being said :). > > Further comments welcome. Well, I think you should go for another Operating System. Linux' core data structures are not designed for such a tiny amount of RAM. Lots of core data structures really are pretty big. Look at task_struct for an example. It doesn't mean they are bloated (task_struct is pretty small, if you look at how much _features_ it implements), but there simply are so many features that you simply don't need on such a small device. And cluttering all the stuff with #ifdefs is not going to lead anywhere. Just take a kernel that fits your needs. I think Linux doesn't. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3] Add SPI over GPIO driver
On Friday 17 October 2008 05:14:26 Magnus Damm wrote: > On Mon, Jul 21, 2008 at 4:46 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > This adds a driver that lets you drive an SPI bus over > > generic GPIO pins. > > > > Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > > Very useful. Fits my shiny new GPIO implementation for SuperH like a glove. > > Michael, as you know, I have some SuperH board code that makes use of > this driver. Are there any outstanding issues with this driver that I > can help resolving? bool cs_activelow should probably be removed from struct spi_gpio_platform_data. I think cs always is activelow, so we can simply hardcode this in spi_gpio_chipselect() If you want to do this, please feel free to do so. I currently don't have the time for this. The rest of the driver is fine with me. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar7-vlynq: support for autodetecting remote clock generation
On Tuesday 11 November 2008 22:20:07 Antti Seppälä wrote:
> +static void vlynq_reset(struct vlynq_device *dev)
> +{
> + vlynq_reg_write(dev->local->control,
> + vlynq_reg_read(dev->local->control) |
> + VLYNQ_CTRL_RESET);
> +
> + /* Wait for the devices to finish resetting */
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(msecs_to_jiffies(5));
If you do an interruptible sleep, you also have to check if you got interrupted.
Otherwise an interruptible sleep doesn't make much sense.
But I think you want msleep(5) here anyway.
> +
> + /* Remove reset bit */
> + vlynq_reg_write(dev->local->control,
> + vlynq_reg_read(dev->local->control) &
> + ~VLYNQ_CTRL_RESET);
> +
> + /* Give some time for the devices to settle */
> + set_current_state(TASK_INTERRUPTIBLE);
> + schedule_timeout(msecs_to_jiffies(5));
Same here.
--
Greetings Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] AP/master mode with b43
On Wednesday 12 November 2008 14:22:46 Brian J. Murrell wrote: > I can see in the bottom-half where all of those are handled except > B43_IRQ_DMA. I don't see anywhere in the whole driver where that is > handled in fact. It's handled implicitely by the DMA handling. You can ignore that IRQ. What's not handled correctly is the PMQ and TBTT indication IRQs. See the FIXMEs and TODOs in the code that handle these IRQs. Good luck. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] AP/master mode with b43
On Wednesday 12 November 2008 13:09:52 Brian J. Murrell wrote:
> On Wed, 2008-11-12 at 12:39 +0100, Michael Buesch wrote:
> > On Wednesday 12 November 2008 04:27:14 Brian J. Murrell wrote:
> > > Please excuse the cross-posting but this thread started on openwrt-users
> > > but the findings are probably more relevant to the developers.
> > >
> > > On Tue, 2008-10-21 at 17:46 +0200, Michael Buesch wrote:
> > > >
> > > > Lookup b43_interrupt_handler() and look for the "reason" variable.
> > > > Fairly straightforward, IMO.
> > >
> > > OK. I've managed to tool up a b43.ko with a printk and this is what I
> > > see, before I even pump anything through the wireless link (i.e. up in
> > > Master mode, and idle):
> >
> > Did you print the value _after_ it was masked with the mask? It seems you
> > didn't.
>
> All I did was:
>
> if (b43_status(dev) < B43_STAT_STARTED)
> goto out;
> reason = b43_read32(dev, B43_MMIO_GEN_IRQ_REASON);
> + /* don't print transmits */
> + if (reason & B43_IRQ_TX_OK)
> + ;
> + else
> + printk(KERN_INFO "b43_interrupt_handler: 0x%x\n", reason);
> if (reason == 0x) /* shared IRQ */
> goto out;
> ret = IRQ_HANDLED;
Yeah, wrong.
Do it later _after_ checking for shared IRQ and after the masking.
1892 static irqreturn_t b43_interrupt_handler(int irq, void *dev_id)
1893 {
1894 irqreturn_t ret = IRQ_NONE;
1895 struct b43_wldev *dev = dev_id;
1896 u32 reason;
1897
1898 if (!dev)
1899 return IRQ_NONE;
1900
1901 spin_lock(&dev->wl->irq_lock);
1902
1903 if (b43_status(dev) < B43_STAT_STARTED)
1904 goto out;
1905 reason = b43_read32(dev, B43_MMIO_GEN_IRQ_REASON);
1906 if (reason == 0x) /* shared IRQ */
1907 goto out;
1908 ret = IRQ_HANDLED;
1909 reason &= b43_read32(dev, B43_MMIO_GEN_IRQ_MASK);
1910 if (!reason)
1911 goto out;
<<< Insert printk code here >>>
Otherwise your printks are completely bogus and not useful at all.
--
Greetings Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] AP/master mode with b43
On Wednesday 12 November 2008 04:27:14 Brian J. Murrell wrote: > Please excuse the cross-posting but this thread started on openwrt-users > but the findings are probably more relevant to the developers. > > On Tue, 2008-10-21 at 17:46 +0200, Michael Buesch wrote: > > > > Lookup b43_interrupt_handler() and look for the "reason" variable. > > Fairly straightforward, IMO. > > OK. I've managed to tool up a b43.ko with a printk and this is what I > see, before I even pump anything through the wireless link (i.e. up in > Master mode, and idle): Did you print the value _after_ it was masked with the mask? It seems you didn't. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar7-vlynq: support for autodetecting remote clock generation
On Wednesday 12 November 2008 20:23:27 Antti Seppälä wrote: > I hope something like this will make it into the repository :) Please also make sure to submit it for inclusion in the mainline kernel, if this driver is part of the vanilla mainline kernel.org kernel. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] AP/master mode with b43
On Wednesday 12 November 2008 15:29:52 Brian J. Murrell wrote: > On Wed, 2008-11-12 at 15:22 +0100, Michael Buesch wrote: > > On Wednesday 12 November 2008 14:22:46 Brian J. Murrell wrote: > > > I can see in the bottom-half where all of those are handled except > > > B43_IRQ_DMA. I don't see anywhere in the whole driver where that is > > > handled in fact. > > > > It's handled implicitely by the DMA handling. You can ignore that IRQ. > > OK. > > > What's not handled correctly is the PMQ and TBTT indication IRQs. > > See the FIXMEs and TODOs in the code that handle these IRQs. > > Indeed. So that's the root of the high softirqs on an AP? Well, could be, if they trigger often (hundreds of times per second), maybe because the IRQ needs to be ACKed in some way, for example. I don't know. >From your logs it's rather hard to tell, because the logs don't have timestamps. So if you show me a log with lots of $foobar triggering, I don't know whether it is due to the long runtime or due to a real flood. So I cannot get a "feeling" of what's going on. But that special feeling often is _the_ key to resolve strange IRQ issues. So it would be cool, if you could turn on printk timestamps in the kernel config "kernel hacking" menu. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] AP/master mode with b43
On Thursday 13 November 2008 00:41:47 Brian J. Murrell wrote: > On Thu, 2008-11-13 at 00:17 +0100, Michael Buesch wrote: > > > > Well, could be, if they trigger often (hundreds of times per second), > > maybe because the IRQ needs to be ACKed in some way, for example. > > Yeah. > > > From your logs it's rather hard to tell, because the logs don't have > > timestamps. > > Yeah, I had considered this as well. > > > So if you show me a log with lots of $foobar triggering, I don't know > > whether it is due to the long runtime or due to a real flood. > > Agreed. > > > So it would be cool, if you could turn on printk timestamps in the kernel > > config "kernel hacking" menu. > > Wasn't even that difficult in fact. > > # echo Y > /sys/module/printk/parameters/time > > So on even an "idle" link: > > [169202.542498] b43_interrupt_handler: 0x4 > [169202.646504] b43_interrupt_handler: 0x4 > [169202.746510] b43_interrupt_handler: 0x4 > [169202.850517] b43_interrupt_handler: 0x4 > [169202.954523] b43_interrupt_handler: 0x4 > [169203.054530] b43_interrupt_handler: 0x4 > [169203.158536] b43_interrupt_handler: 0x4 > [169203.258542] b43_interrupt_handler: 0x4 > [169203.362549] b43_interrupt_handler: 0x4 > [169203.466555] b43_interrupt_handler: 0x4 > [169203.566562] b43_interrupt_handler: 0x4 > [169203.670568] b43_interrupt_handler: 0x4 > [169203.770574] b43_interrupt_handler: 0x4 > [169203.874581] b43_interrupt_handler: 0x4 > [169203.978587] b43_interrupt_handler: 0x4 > [169204.078594] b43_interrupt_handler: 0x4 > [169204.182600] b43_interrupt_handler: 0x4 > [169204.282606] b43_interrupt_handler: 0x4 > [169204.386613] b43_interrupt_handler: 0x4 > [169204.490619] b43_interrupt_handler: 0x4 > [169204.590626] b43_interrupt_handler: 0x4 > [169204.694632] b43_interrupt_handler: 0x4 > [169204.794638] b43_interrupt_handler: 0x4 > > Which is a B43_IRQ_TBTT_INDI every .1s or so. During a period of load > and high softirq, it doesn't seem much worse: .1 seconds isn't actually _that_ often. I think actually, it could probably be correct. TBTT_INDI means Target Beacon Transmit Time Indication. Beacons are transmitted at a .1024 seconds interval. I'm currently unsure, however, what this IRQ is used for and if it should really trigger once per beacon. Probably not. Anyway, can you try masking IRQ 0x4 and if that doesn't improve it also 0x40? Just go to b43.h search #define B43_IRQ_MASKTEMPLATE and remove the B43_IRQ_TBTT_INDI and/or B43_IRQ_PMQ from this definition. Another question: How often does the template update trigger? -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Users] AP/master mode with b43
On Thursday 13 November 2008 01:39:21 Brian J. Murrell wrote: > OK. Masking out 0x4 didn't improve the softirq on bulk data, but > masking out 0x40 as well made the wireless interface unusable. Couldn't > even ping through it. Ok, well. But did it reduce the massive CPU usage? > messages? Currently with both of those IRQs masked off (and the > interface up but not really working) only at driver load time: And otherwise, with the IRQs unmasked? -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Commits] r13610 - branches/8.09/target/linux/brcm47xx/patches-2.6.25 trunk/target/linux/brcm47xx/patches-2.6.25
On Friday 12 December 2008 01:59:48 openwrt-comm...@openwrt.org wrote:
> Added:
> branches/8.09/target/linux/brcm47xx/patches-2.6.25/211-b44_bcm4713_phy.patch
> ===
> ---
> branches/8.09/target/linux/brcm47xx/patches-2.6.25/211-b44_bcm4713_phy.patch
> (rev 0)
> +++
> branches/8.09/target/linux/brcm47xx/patches-2.6.25/211-b44_bcm4713_phy.patch
> 2008-12-12 00:59:47 UTC (rev 13610)
> @@ -0,0 +1,14 @@
> +--- a/drivers/net/b44.c 2008-11-16 15:33:32.0 +0100
> b/drivers/net/b44.c 2008-11-18 10:36:18.0 +0100
> +@@ -2094,6 +2094,11 @@
> + return -EINVAL;
> + }
> +
> ++if (bp->sdev->id.coreid == 0x806 && bp->sdev->id.revision == 0x0) {
> ++bp->phy_addr = B44_PHY_ADDR_NO_PHY;
> ++bp->dma_offset = 0;
> ++}
> ++
this is a little bit weird.
coreid == 0x806 will always be true.
So you will always set phy_addr to NO_PHY for every device with core revision
0. That smells like
incorrect code to me...
--
Greetings, Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Commits] r13610 - branches/8.09/target/linux/brcm47xx/patches-2.6.25 trunk/target/linux/brcm47xx/patches-2.6.25
On Friday 12 December 2008 02:32:53 Florian Fainelli wrote:
> Le Friday 12 December 2008 02:25:00 Michael Buesch, vous avez écrit :
> > On Friday 12 December 2008 01:59:48 openwrt-comm...@openwrt.org wrote:
> > > Added:
> > > branches/8.09/target/linux/brcm47xx/patches-2.6.25/211-b44_bcm4713_phy.pa
> > >tch ===
> > > ---
> > > branches/8.09/target/linux/brcm47xx/patches-2.6.25/211-b44_bcm4713_phy.pa
> > >tch(rev 0) +++
> > > branches/8.09/target/linux/brcm47xx/patches-2.6.25/211-b44_bcm4713_phy.pa
> > >tch2008-12-12 00:59:47 UTC (rev 13610) @@ -0,0 +1,14 @@
> > > +--- a/drivers/net/b44.c 2008-11-16 15:33:32.0 +0100
> > > b/drivers/net/b44.c 2008-11-18 10:36:18.0 +0100
> > > +@@ -2094,6 +2094,11 @@
> > > + return -EINVAL;
> > > + }
> > > +
> > > ++if (bp->sdev->id.coreid == 0x806 && bp->sdev->id.revision ==
> > > 0x0) {
> > > ++bp->phy_addr = B44_PHY_ADDR_NO_PHY;
> > > ++bp->dma_offset = 0;
> > > ++}
> > > ++
> >
> > this is a little bit weird.
> > coreid == 0x806 will always be true.
> > So you will always set phy_addr to NO_PHY for every device with core
> > revision 0. That smells like incorrect code to me...
>
> I tested it with success on an Asus WL500G Deluxe. Will do more testing on a
> WRT54GS.
Well, it will break PCI devices, however.
I think you should probably check for
if (sdev->bus->chip_id == 0xfoobar && sdev->id.revision == 0)
--
Greetings, Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Commits] r13610 - b ranches/8.09/target/linux/brcm47xx/patches-2.6.25 tr unk/target/linux/brcm47xx/patches-2.6.25
On Friday 12 December 2008 14:09:27 Felix Fietkau wrote:
> Florian Fainelli wrote:
> > Le Friday 12 December 2008 02:25:00 Michael Buesch, vous avez écrit :
> >> On Friday 12 December 2008 01:59:48 openwrt-comm...@openwrt.org wrote:
> >> > Added:
> >> > branches/8.09/target/linux/brcm47xx/patches-2.6.25/211-b44_bcm4713_phy
> >> >.pa tch
> >> > ===
> >> > ---
> >> > branches/8.09/target/linux/brcm47xx/patches-2.6.25/211-b44_bcm4713_phy
> >> >.pa tch (rev 0) +++
> >> > branches/8.09/target/linux/brcm47xx/patches-2.6.25/211-b44_bcm4713_phy
> >> >.pa tch 2008-12-12 00:59:47 UTC (rev 13610) @@ -0,0 +1,14 @@
> >> > +--- a/drivers/net/b44.c 2008-11-16 15:33:32.0 +0100
> >> > b/drivers/net/b44.c 2008-11-18 10:36:18.0 +0100
> >> > +@@ -2094,6 +2094,11 @@
> >> > +return -EINVAL;
> >> > +}
> >> > +
> >> > ++ if (bp->sdev->id.coreid == 0x806 && bp->sdev->id.revision ==
> >> > 0x0) {
> >> > ++ bp->phy_addr = B44_PHY_ADDR_NO_PHY;
> >> > ++ bp->dma_offset = 0;
> >> > ++ }
> >> > ++
> >>
> >> this is a little bit weird.
> >> coreid == 0x806 will always be true.
> >> So you will always set phy_addr to NO_PHY for every device with core
> >> revision 0. That smells like incorrect code to me...
> >
> > I tested it with success on an Asus WL500G Deluxe. Will do more testing
> > on a WRT54GS.
>
> I also think that code is wrong. Whether the device has a PHY
> connected or not depends on the actual board, not the chip.
> So PHY related checks should probably depend on some nvram values
> and should be #ifdef'd for CONFIG_BRCM47xx
Right. bus->boardinfo probably is the way to go here. Probably also a check
for bus->chip_id/rev. I'm not sure on that.
sdev->id certainly is not correct. I'm pretty sure I own a device where the
original
patch would break things. (I'm too lazy to check now).
--
Greetings, Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] enlightenment RequireCommand
Why do we need the following RequireCommand in enlightenment? $(eval $(call RequireCommand,edje_cc, \ Command not found - please install edje with edje-cc enabled \ )) $(eval $(call RequireCommand,eet, \ Command not found - please install eet \ )) As far as I understand, this checks for the two commands on the build host system. Why? Why don't we simply build the tools? Don't we actually _do_ the build already? I guess so, because the configure target redirects these commands to staging: define Build/Configure (cd $(PKG_BUILD_DIR); NOCONFIGURE=YES ./autogen.sh ); $(call Build/Configure/Default, --with-edje-cc=$(STAGING_DIR_HOST)/usr/bin/edje_cc --with-eet-eet=$(STAGING_DIR_HOST)/usr/bin/eet) endef -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] enlightenment RequireCommand
On Monday 29 December 2008 23:10:21 Mirko Vogt wrote: > Michael Buesch wrote: > > Why do we need the following RequireCommand in enlightenment? > > > > $(eval $(call RequireCommand,edje_cc, \ > > Command not found - please install edje with edje-cc enabled \ > > )) > > $(eval $(call RequireCommand,eet, \ > > Command not found - please install eet \ > > )) > > > > As far as I understand, this checks for the two commands on the build host > > system. > Yep. > > Why? Why don't we simply build the tools? > Because building native host tools isn't possible in a nice way yet. > > Don't we actually _do_ the build already? > No, building of edje_cc is disabled in the Makefile. Ok, which debian package do I need for edje_cc? I installed e16, but it still bails out. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] libevent download link is broken
mkdir -p /home/mb/develop/svn/openwrt_moko/trunk/dl /home/mb/develop/svn/openwrt_moko/trunk/scripts/download.pl "/home/mb/develop/svn/openwrt_moko/trunk/dl" "libevent-1.4.4-stable.tar.gz" "5d7591aa6301f06315b52bade472bf2f" http://www.monkey.org/~provos/ --2008-12-30 21:42:48-- http://www.monkey.org/~provos/libevent-1.4.4-stable.tar.gz Resolving www.monkey.org... failed: Connection timed out. wget: unable to resolve host address `www.monkey.org' Download failed. --2008-12-30 21:43:08-- http://mirror2.openwrt.org/sources/libevent-1.4.4-stable.tar.gz Resolving mirror2.openwrt.org... 88.198.39.176 Connecting to mirror2.openwrt.org|88.198.39.176|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2008-12-30 21:43:09 ERROR 404: Not Found. Download failed. --2008-12-30 21:43:09-- http://downloads.openwrt.org/sources/libevent-1.4.4-stable.tar.gz Resolving downloads.openwrt.org... 195.56.146.238 Connecting to downloads.openwrt.org|195.56.146.238|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2008-12-30 21:43:13 ERROR 404: Not Found. Download failed. No more mirrors to try - giving up. make[3]: *** [/home/mb/develop/svn/openwrt_moko/trunk/dl/libevent-1.4.4-stable.tar.gz] Error 2 make[3]: Leaving directory `/home/mb/develop/svn/openwrt_moko/packages/libs/libevent' make[2]: *** [package/packages/libs/libevent/compile] Error 2 make[2]: Leaving directory `/home/mb/develop/svn/openwrt_moko/trunk' make[1]: *** [/home/mb/develop/svn/openwrt_moko/trunk/staging_dir/arm/stamp/.package_compile] Error 2 make[1]: Leaving directory `/home/mb/develop/svn/openwrt_moko/trunk' make: *** [world] Error 2 -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] libevent download link is broken
On Tuesday 30 December 2008 21:48:42 Michael Buesch wrote: > mkdir -p /home/mb/develop/svn/openwrt_moko/trunk/dl > /home/mb/develop/svn/openwrt_moko/trunk/scripts/download.pl > "/home/mb/develop/svn/openwrt_moko/trunk/dl" "libevent-1.4.4-stable.tar.gz" > "5d7591aa6301f06315b52bade472bf2f" http://www.monkey.org/~provos/ > --2008-12-30 21:42:48-- > http://www.monkey.org/~provos/libevent-1.4.4-stable.tar.gz > Resolving www.monkey.org... failed: Connection timed out. > wget: unable to resolve host address `www.monkey.org' > Download failed. > --2008-12-30 21:43:08-- > http://mirror2.openwrt.org/sources/libevent-1.4.4-stable.tar.gz > Resolving mirror2.openwrt.org... 88.198.39.176 > Connecting to mirror2.openwrt.org|88.198.39.176|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 2008-12-30 21:43:09 ERROR 404: Not Found. Here's a working link: http://ftp.devil-linux.org/pub/devel/sources/1.3/libevent-1.4.4-stable.tar.gz Can somebody download it into http://mirror2.openwrt.org/sources, please? -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ecore depend on xcb
What about the following patch? It enables compilation of e17 when xlib is not available. This is required for the openmoko build target. Can this break something? Index: Xorg/efl/ecore/Makefile === --- Xorg/efl/ecore/Makefile (revision 13787) +++ Xorg/efl/ecore/Makefile (working copy) @@ -30,7 +30,7 @@ SUBMENU:=lib TITLE:=Ecore is the core event abstraction layer and X abstraction layer URL:=http://wiki.enlightenment.org/index.php/Ecore - DEPENDS:=+eet +evas +libXcursor +libXrandr +libXtst +libiconv + DEPENDS:=+eet +evas +libXcursor +libXrandr +libXtst +libiconv +libxcb-xlib endef define Package/ecore/description @@ -46,7 +46,6 @@ --with-iconv-link \ --enable-ecore-txt \ --disable-ecore-config \ ---disable-ecore-x-xcb \ --enable-ecore-x \ --enable-ecore-job \ --disable-ecore-directfb \ -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ecore depend on xcb
On Thursday 01 January 2009 16:02:17 Lars-Peter Clausen wrote: > Michael Buesch wrote: > > What about the following patch? > > It enables compilation of e17 when xlib is not available. > > This is required for the openmoko build target. > > > > Can this break something? > > > > Index: Xorg/efl/ecore/Makefile > > === > > --- Xorg/efl/ecore/Makefile(revision 13787) > > +++ Xorg/efl/ecore/Makefile(working copy) > > @@ -30,7 +30,7 @@ > >SUBMENU:=lib > >TITLE:=Ecore is the core event abstraction layer and X abstraction layer > >URL:=http://wiki.enlightenment.org/index.php/Ecore > > - DEPENDS:=+eet +evas +libXcursor +libXrandr +libXtst +libiconv > > + DEPENDS:=+eet +evas +libXcursor +libXrandr +libXtst +libiconv > +libxcb-xlib > > endef > > > > define Package/ecore/description > > @@ -46,7 +46,6 @@ > > --with-iconv-link \ > > --enable-ecore-txt \ > > --disable-ecore-config \ > > ---disable-ecore-x-xcb \ > > --enable-ecore-x \ > > --enable-ecore-job \ > > --disable-ecore-directfb \ > > > Hi > > Why is xlib not available for the openmoko target? I don't know the details. It's not available. I think that's enough of a reason. ;) > And as far as I can see if you want to use xcb in ecore you need the > libxcb package and not libxcb-xlib. It works properly with this dep. > Anyway the idea is to switch everything to using xcb soon. Ok, well. So the first question is void anyway. :P -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] development workflow for kernel patching
On Tuesday 20 January 2009 16:09:56 RB wrote:
> On Tue, Jan 20, 2009 at 00:30, Warren Turkal wrote:
> > 1. What specific kernel version is the 2.6.28 kernel patch set
> > designed to be applied (2.6.28 or 2.6.28.1)? How do I look this
> > information up for myself?
>
> That's set in the LINUX_VERSION variable in the target's Makefile
> (target/linux/brcm47xx/Makefile). Since that's still set to a 2.6.25
> series AFAICT, it looks like the 2.6.28 portion is just staged and not
> yet intended to build.
>
> > 2. What is a good workflow for applying part of the series of patches
> > so that I can make a modification to a specific patch?
>
> If you can unravel the spaghetti-soup Makefile mess and figure that
> out, please let us all know. I've typically just hand-patched until I
> got where I needed.
You can also use the builtin quilt support in buildroot.
That's pretty easy to use.
make QUILT=1 target/linux-{clean,prepare}
cd build_dir/foobar
quilt push, pop, etc...
vi edit_file
quilt refresh
make target/linux-update
--
Greetings, Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Resume work on Asus WL500g2 (LP-PHY)
I just want to note that I resumed work on the WL500gV2, which has a b43 based LP-PHY wireless device. I cannot make any guarantees or timelines, just that it's done when it's done. I'll first look into making the serial port work. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Resume work on Asus WL500g2 (LP-PHY)
On Tuesday 27 January 2009 12:42:20 Robert P. J. Day wrote: > On Mon, 26 Jan 2009, Michael Buesch wrote: > > > I just want to note that I resumed work on the WL500gV2, which > > has a b43 based LP-PHY wireless device. > > I cannot make any guarantees or timelines, just that it's done when it's > > done. > > I'll first look into making the serial port work. > > i'm particularly interested in this project, since i love my V1 but > it's getting harder to find them, while the V2s are far more common. > let me know if i can do anything to help. i can start by going out > and getting one. :-) Yes, you can help me a lot. I just bricked it. Can you be so kind to give me images of your CFE and NVRAM partitions of a working v2 device? You can read them with the mtd utility in linux. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Resume work on Asus WL500g2 (LP-PHY)
On Wednesday 28 January 2009 12:47:48 Robert P. J. Day wrote: > On Wed, 28 Jan 2009, Michael Buesch wrote: > > > On Tuesday 27 January 2009 12:42:20 Robert P. J. Day wrote: > > > On Mon, 26 Jan 2009, Michael Buesch wrote: > > > > > > > I just want to note that I resumed work on the WL500gV2, which > > > > has a b43 based LP-PHY wireless device. > > > > I cannot make any guarantees or timelines, just that it's done when > > > > it's done. > > > > I'll first look into making the serial port work. > > > > > > i'm particularly interested in this project, since i love my V1 but > > > it's getting harder to find them, while the V2s are far more common. > > > let me know if i can do anything to help. i can start by going out > > > and getting one. :-) > > > > Yes, you can help me a lot. I just bricked it. Can you be so kind to > > give me images of your CFE and NVRAM partitions of a working v2 > > device? You can read them with the mtd utility in linux. > > you'll have to wait until later today as i was just going out to get > one later this morning. unless someone else can help you out more > quickly. No need to hurry. I just flashed some modified CFE that switches the LEDs in the early boot code to verify that my flash tools work properly, etc... So next one will be that I try my own compiled (probably modified) CFE. If that doesn't work, I'll try your CFE image from the original router. Next time I will make a backup copy before poking with flash. :D I usually do this. Just not with this device. :( In the long term I'm also interested in uboot on the device, as CFE just sucks balls. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] HairyDairy buffer overflow
On Wednesday 28 January 2009 14:17:35 Benjamin Henrion wrote: > Hi, > > I have just had a problem with the HairyDairy JTAG tool: > > http://zoobab.wikidot.com/hairy-dairy-buffer-overflow > > I filed a bug report here: > > https://dev.openwrt.org/ticket/4514 > Nice catch. I applied a fix to my private fork of the tool: http://bu3sch.de/gitweb?p=wrt-debrick.git;a=commitdiff_plain;h=a615efbfa49b4d815ab5f71217c94d6b99feb5af I'm not sure if anybody still maintains the original debrick tool. There's also a fork called tjtag. It also has this bug. So you may want to report it to these guys, too. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] HairyDairy buffer overflow
On Thursday 29 January 2009 10:02:00 Benjamin Henrion wrote: > On Wed, Jan 28, 2009 at 11:13 PM, Michael Buesch wrote: > > On Wednesday 28 January 2009 14:17:35 Benjamin Henrion wrote: > >> Hi, > >> > >> I have just had a problem with the HairyDairy JTAG tool: > >> > >> http://zoobab.wikidot.com/hairy-dairy-buffer-overflow > >> > >> I filed a bug report here: > >> > >> https://dev.openwrt.org/ticket/4514 > >> > > > > Nice catch. I applied a fix to my private fork of the tool: > > http://bu3sch.de/gitweb?p=wrt-debrick.git;a=commitdiff_plain;h=a615efbfa49b4d815ab5f71217c94d6b99feb5af > > > > I'm not sure if anybody still maintains the original debrick tool. > > There's also a fork called tjtag. It also has this bug. So you may want to > > report it to these guys, too. > > I have only seen binaries of Tjtag, no sources around. But it supports > more SoC and flashes. http://www.dd-wrt.com/dd-wrtv2/down.php?path=downloads%2Fothers%2Ftornado%2Fjtag/ -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Resume work on Asus WL500g2 (LP-PHY)
On Tuesday 27 January 2009 12:42:20 Robert P. J. Day wrote: > On Mon, 26 Jan 2009, Michael Buesch wrote: > > > I just want to note that I resumed work on the WL500gV2, which > > has a b43 based LP-PHY wireless device. > > I cannot make any guarantees or timelines, just that it's done when it's > > done. > > I'll first look into making the serial port work. > > i'm particularly interested in this project, since i love my V1 but > it's getting harder to find them, while the V2s are far more common. > let me know if i can do anything to help. i can start by going out > and getting one. :-) I just want to note that I successfully compiled a working CFE now and the router is back to life. :) So no need to hurry for you. I'm back at work. Also note that the device boots into linux and serial does also work. The b43 driver currently crashes the device. I'm debugging this... Note that the kernel SSB currently doesn't have PMU support. So we currently depend on CFE correctly initializing the PMU. That may be related to some crashes and I should probably implement some PMU support... -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] please reopen ticket 3152
On Sunday 01 February 2009 16:24:49 Brian J. Murrell wrote: > I've just posted some more details to ticket #3152 which is currently > closed. Could somebody with permission to do so, please reopen it? > > Basically, I'm getting: > > b43-phy2: Broadcom 4318 WLAN found > phy2: Selected rate control algorithm 'pid' > Broadcom 43xx driver loaded [ Features: NLR, Firmware-ID: FW13 ] > input: b43-phy2 as /devices/virtual/input/input3 > b43-phy2 ERROR: Firmware file "b43/b0g0initvals5.fw" not found > b43-phy2 ERROR: You must go to > http://linuxwireless.org/en/users/Drivers/b43#devicefirmware and download the > latest firmware (version 4). > > Trying to do: > > insmod b43 > ifconfig wlan0 up > > But the file most certainly exists: > > r...@gw:~# ls -l /lib/firmware/b43/ > -rw-r--r--1 root root 18 Jan 31 11:36 a0g0bsinitvals4.fw > -rw-r--r--1 root root 158 Jan 31 11:36 a0g0bsinitvals5.fw > -rw-r--r--1 root root 158 Jan 31 11:36 a0g0bsinitvals9.fw > ... > -rw-r--r--1 root root 158 Jan 31 11:36 b0g0bsinitvals5.fw > ... I do not see the failed file here. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] b43 good news and bad news
On Tuesday 03 February 2009 20:41:06 Brian J. Murrell wrote: > On Tue, 2009-02-03 at 20:16 +0100, Michael Buesch wrote: > > On Tuesday 03 February 2009 05:44:42 Brian J. Murrell wrote: > > > The bad news is that throughput still sucks rocks. > > Sorry if that sounded harsh. It didn't seem as harsh when I was writing > it as it did just now reading it. I meant no ill-will in any way by it. > Just trying to be frank I guess. I'm not known for beating around the > bush. :-) > > > This is unlikely to change ever, except if broadcom releases the sources. > > OK. That's fair enough. I was just trying to supply some feedback in > case it was in fact unexpected. I thought full throughput was being > targeted by the current reverse engineering effort. No. 802.11g-PHY support is defacto not developed anymore in b43. We're currently working on 802.11g-LP-PHY and 802.11n. > I can totally understand if it will never be achieved. Well, the problem is that nobody understands what the code does. So it's simply unlikely that somebody will find the bugs by just looking at the code. So there are only two choices: 1) Somebody who reverse engineered the code will check the open code for bugs (once again). -> This is not going to happen. 2) Broadcom releases sources and somebody ports it to b43. So well. b43 in AP mode does actually work properly. I use it in AP mode, too. But it's of no use, if you need huge throughput. If you just want to surf the internet, it's good enough most of the time. I get about 1MByte/sec on my 4318. That's enough for websurfing. Big files are transferred over the gbit ethernet anyway. > > Go and buy a device that's actually vendor supported, if you want full > > throughput. > > Yeah. Given that it's got a minipci slot in it, maybe an atheros or > something. Atheros is the best bet, I'd say. But _first_ check to buy a supported card. > I did in fact buy an ipw2200 based card "on spec" hoping to ipw2200? Come on. You want to make me puke. :) That's a _lot_ worse than any broadcom card (even those bcm cards that don't work at all). It's the biggest pile of crap ever built. :) The ipw2200 doesn't even work correctly in STA mode. No chance for AP ever. BTW: Anybody want an almost unused ipw2200? You get it for free from me. :) -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] b43 good news and bad news
On Tuesday 03 February 2009 05:44:42 Brian J. Murrell wrote: > The bad news is that throughput still sucks rocks. This is unlikely to change ever, except if broadcom releases the sources. Go and buy a device that's actually vendor supported, if you want full throughput. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] bcm47xx: Fix GPIO API return codes
The GPIO API is supposed to return 0 or a negative error code,
but the SSB GPIO functions return the bitmask of the GPIO register.
Fix this by ignoring the bitmask and always returning 0. The SSB GPIO functions
can't fail.
Signed-off-by: Michael Buesch
---
Index: linux-2.6/arch/mips/include/asm/mach-bcm47xx/gpio.h
===
--- linux-2.6.orig/arch/mips/include/asm/mach-bcm47xx/gpio.h2009-01-01
19:27:06.0 +0100
+++ linux-2.6/arch/mips/include/asm/mach-bcm47xx/gpio.h 2009-02-14
21:26:14.0 +0100
@@ -31,24 +31,28 @@ static inline void gpio_set_value(unsign
static inline int gpio_direction_input(unsigned gpio)
{
- return ssb_gpio_outen(&ssb_bcm47xx, 1 << gpio, 0);
+ ssb_gpio_outen(&ssb_bcm47xx, 1 << gpio, 0);
+ return 0;
}
static inline int gpio_direction_output(unsigned gpio, int value)
{
- return ssb_gpio_outen(&ssb_bcm47xx, 1 << gpio, 1 << gpio);
+ ssb_gpio_outen(&ssb_bcm47xx, 1 << gpio, 1 << gpio);
+ return 0;
}
-static int gpio_intmask(unsigned gpio, int value)
+static inline int gpio_intmask(unsigned gpio, int value)
{
- return ssb_gpio_intmask(&ssb_bcm47xx, 1 << gpio,
- value ? 1 << gpio : 0);
+ ssb_gpio_intmask(&ssb_bcm47xx, 1 << gpio,
+value ? 1 << gpio : 0);
+ return 0;
}
-static int gpio_polarity(unsigned gpio, int value)
+static inline int gpio_polarity(unsigned gpio, int value)
{
- return ssb_gpio_polarity(&ssb_bcm47xx, 1 << gpio,
-value ? 1 << gpio : 0);
+ ssb_gpio_polarity(&ssb_bcm47xx, 1 << gpio,
+ value ? 1 << gpio : 0);
+ return 0;
}
--
Greetings, Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bcm47xx: Fix GPIO API return codes
On Sunday 15 February 2009 14:27:36 Florian Fainelli wrote: > Hi Michael, > > Le Saturday 14 February 2009 21:27:19 Michael Buesch, vous avez écrit : > > The GPIO API is supposed to return 0 or a negative error code, > > but the SSB GPIO functions return the bitmask of the GPIO register. > > Fix this by ignoring the bitmask and always returning 0. The SSB GPIO > > functions can't fail. > > At some point we might want to convert the existing board code to use > gpiolib. > I will try to come up with a patch for this later this afternoon. Well, why? What's the advantage? I think it would degrade performance even more, due to yet another few function calls in the hotpath. And yes, performance does matter. The only reason the optional inlined GPIO API exists is to avoid the gpiolib callbacks on platforms where the GPIO numbers are written in stone anyway. And that's the case for bcm47xx -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] spi-gpio: Sanitize MISO bitvalue
gpio_get_value() returns 0 or nonzero, but getmiso() expects 0 or 1.
Sanitize the value to a 0/1 boolean.
Signed-off-by: Michael Buesch
---
Well, we could also change the bitbang helpers in linux/spi/spi_bitbang.h
or change the way the gpio_get_value API is defined, but I personally think
this patch is pretty good as is.
In any case, it fixes a real bug on platforms like the bcm47xx which
return 0 or nonzero for gpio_get_value.
Index: linux-2.6/drivers/spi/spi_gpio.c
===
--- linux-2.6.orig/drivers/spi/spi_gpio.c 2009-02-14 21:37:14.0
+0100
+++ linux-2.6/drivers/spi/spi_gpio.c2009-02-15 16:27:16.0 +0100
@@ -114,7 +114,7 @@ static inline void setmosi(const struct
static inline int getmiso(const struct spi_device *spi)
{
- return gpio_get_value(SPI_MISO_GPIO);
+ return !!gpio_get_value(SPI_MISO_GPIO);
}
#undef pdata
--
Greetings, Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] spi-gpio: Implement spidelay() for busses that need it.
Implement the SPI-GPIO delay function for busses that need speed limitation.
If the special all-inline API is used, the delay is disabled at compiletime.
Otherwise it's an unlikely condition that can be disabled via max_speed_hz.
So it should have minimal or zero impact on the speed of implementations
without delay.
Signed-off-by: Michael Buesch
---
I need this delay when using a slow microcontroller attached via SPI-GPIO
to a fast embedded router device.
Index: linux-2.6/drivers/spi/spi_gpio.c
===
--- linux-2.6.orig/drivers/spi/spi_gpio.c 2009-02-15 16:27:16.0
+0100
+++ linux-2.6/drivers/spi/spi_gpio.c2009-02-15 19:19:36.0 +0100
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -69,6 +70,7 @@ struct spi_gpio {
* #define SPI_MOSI_GPIO 120
* #define SPI_SCK_GPIO121
* #define SPI_N_CHIPSEL 4
+ * #undef NEED_SPIDELAY
* #include "spi_gpio.c"
*/
@@ -76,6 +78,7 @@ struct spi_gpio {
#define DRIVER_NAME"spi_gpio"
#define GENERIC_BITBANG/* vs tight inlines */
+#define NEED_SPIDELAY 1
/* all functions referencing these symbols must define pdata */
#define SPI_MISO_GPIO ((pdata)->miso)
@@ -120,12 +123,20 @@ static inline int getmiso(const struct s
#undef pdata
/*
- * NOTE: this clocks "as fast as we can". It "should" be a function of the
- * requested device clock. Software overhead means we usually have trouble
- * reaching even one Mbit/sec (except when we can inline bitops), so for now
- * we'll just assume we never need additional per-bit slowdowns.
+ * NOTE: to clock "as fast as we can", set spi_device.max_speed_hz
+ * and spi_transfer.speed_hz to 0.
+ * Otherwise this is a function of the requested device clock.
+ * Software overhead means we usually have trouble
+ * reaching even one Mbit/sec (except when we can inline bitops). So on small
+ * embedded devices with fast SPI slaves you usually don't need a delay.
*/
-#define spidelay(nsecs)do {} while (0)
+static inline void spidelay(unsigned nsecs)
+{
+#ifdef NEED_SPIDELAY
+ if (unlikely(nsecs))
+ ndelay(nsecs);
+#endif /* NEED_SPIDELAY */
+}
#defineEXPAND_BITBANG_TXRX
#include
--
Greetings, Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bcm47xx: Fix GPIO API return codes
On Wednesday 18 February 2009 01:29:18 Andrew Morton wrote:
> On Sat, 14 Feb 2009 21:27:19 +0100
> Michael Buesch wrote:
>
> > The GPIO API is supposed to return 0 or a negative error code,
> > but the SSB GPIO functions return the bitmask of the GPIO register.
> > Fix this by ignoring the bitmask and always returning 0. The SSB GPIO
> > functions can't fail.
> >
> > Signed-off-by: Michael Buesch
> >
> > ---
> >
> > Index: linux-2.6/arch/mips/include/asm/mach-bcm47xx/gpio.h
> > ===
> > --- linux-2.6.orig/arch/mips/include/asm/mach-bcm47xx/gpio.h
> > 2009-01-01 19:27:06.0 +0100
> > +++ linux-2.6/arch/mips/include/asm/mach-bcm47xx/gpio.h 2009-02-14
> > 21:26:14.0 +0100
> > @@ -31,24 +31,28 @@ static inline void gpio_set_value(unsign
> >
> > static inline int gpio_direction_input(unsigned gpio)
> > {
> > - return ssb_gpio_outen(&ssb_bcm47xx, 1 << gpio, 0);
> > + ssb_gpio_outen(&ssb_bcm47xx, 1 << gpio, 0);
> > + return 0;
> > }
> >
> > static inline int gpio_direction_output(unsigned gpio, int value)
> > {
> > - return ssb_gpio_outen(&ssb_bcm47xx, 1 << gpio, 1 << gpio);
> > + ssb_gpio_outen(&ssb_bcm47xx, 1 << gpio, 1 << gpio);
> > + return 0;
> > }
> >
> > -static int gpio_intmask(unsigned gpio, int value)
> > +static inline int gpio_intmask(unsigned gpio, int value)
> > {
> > - return ssb_gpio_intmask(&ssb_bcm47xx, 1 << gpio,
> > - value ? 1 << gpio : 0);
> > + ssb_gpio_intmask(&ssb_bcm47xx, 1 << gpio,
> > +value ? 1 << gpio : 0);
> > + return 0;
> > }
> >
> > -static int gpio_polarity(unsigned gpio, int value)
> > +static inline int gpio_polarity(unsigned gpio, int value)
> > {
> > - return ssb_gpio_polarity(&ssb_bcm47xx, 1 << gpio,
> > -value ? 1 << gpio : 0);
> > + ssb_gpio_polarity(&ssb_bcm47xx, 1 << gpio,
> > + value ? 1 << gpio : 0);
> > + return 0;
> > }
>
> What are the consequences of the bug which you fixed? User-visible
> runtime failures? Something else?
>
> Please always include this information in the changelogs - without it I
> cannot make which-kernel-needs-this decisions.
Well, it fixes all users of the API that don't ignore the return value.
"Fixes" means "turns them from completely not working at all into - working
properly".
This is the case for gpio-spi, for example. gpio-spi doesn't work on bcm47xx
without
this fix. gpio-spi is in 2.6.29.
I didn't search for other API-users that might be broken.
So I'd like to see this going to Linus as soon as possible.
--
Greetings, Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] spi-gpio: Sanitize MISO bitvalue
On Wednesday 18 February 2009 22:04:26 Andrew Morton wrote:
> On Sun, 15 Feb 2009 16:30:41 +0100
> Michael Buesch wrote:
>
> > gpio_get_value() returns 0 or nonzero, but getmiso() expects 0 or 1.
> > Sanitize the value to a 0/1 boolean.
> >
> > Signed-off-by: Michael Buesch
> >
> > ---
> >
> > Well, we could also change the bitbang helpers in linux/spi/spi_bitbang.h
> > or change the way the gpio_get_value API is defined, but I personally think
> > this patch is pretty good as is.
> > In any case, it fixes a real bug on platforms like the bcm47xx which
> > return 0 or nonzero for gpio_get_value.
> >
> > Index: linux-2.6/drivers/spi/spi_gpio.c
> > ===
> > --- linux-2.6.orig/drivers/spi/spi_gpio.c 2009-02-14 21:37:14.0
> > +0100
> > +++ linux-2.6/drivers/spi/spi_gpio.c2009-02-15 16:27:16.0
> > +0100
> > @@ -114,7 +114,7 @@ static inline void setmosi(const struct
> >
> > static inline int getmiso(const struct spi_device *spi)
> > {
> > - return gpio_get_value(SPI_MISO_GPIO);
> > + return !!gpio_get_value(SPI_MISO_GPIO);
> > }
> >
> > #undef pdata
> >
>
> Seems somewhat pointless, really. It's a very common C idiom to treat
> any non-zero value as true, and the above just adds a couple more
> instructions which we didn't need to execute.
No you must look at the user of getmiso().
It does something like this:
for (bitnr = 0; bitnr < x; bitnr++) {
foo = getmiso() << bitnr;
...
}
> If this function is speed-critical (which is what David's comment
> implies) then perhaps this should be "fixed" by tightening up the
> (presently apparently undocumented) interface? And then speeding up
> all the other getmiso() implementations?
He was talking about gpio_get_value() and my (silly) suggestion to change
it to return 0 or 1. I knew that he would reject that, because we already talked
about this in the past. So changing getmiso() _is_ the way to go. It is the
cheapest
way to do this, in fact. Doing it _inside_ of getmiso() would mean that it could
possibly be redundant, if upper layers already did it.
David suggested documenting the fact that getmiso() expects 0/1.
He can easily do that in yet another patch if he likes this.
My patch is just supposed to fix a real-world bug, which isn't in a released
kernel, yet.
So if we hurry up, we can still get it into .29.
The documentation change can still go in later.
--
Greetings, Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Commits] r14628 - trunk/target/linux/ar71xx/files/drivers/net/phy
On Sunday 22 February 2009 21:52:13 openwrt-comm...@openwrt.org wrote: > Author: juhosg > Date: 2009-02-22 21:52:12 +0100 (Sun, 22 Feb 2009) > New Revision: 14628 > > Modified: >trunk/target/linux/ar71xx/files/drivers/net/phy/micrel.c > Log: > [ar71xx] micrel phy driver: change initcall level if compiled into the kernel ... > +#ifdef MODULE > module_init(micrel_phy_init); > module_exit(micrel_phy_exit); > +#else > +subsys_initcall(micrel_phy_init); > +#endif This ifdef-ing is not needed. Simply do this: -module_init(micrel_phy_init); +subsys_initcall(micrel_phy_init); module_exit(micrel_phy_exit); It will do the correct thing for you in the built-in and module case.. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.11 broadcom 4321 support
On Thursday 26 February 2009 21:49:28 Andres Aguirre wrote: > http://www.broadcom.com/support/802.11/linux_sta.php the drivers for > kernel 2.6 the only problem is that are for x86 architecture but it > couldn't be so hard to compile in mips architecture. Yes it is, because it is closed source. It's currently impossible to run 4321 on 2.6 kernel. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 802.11 broadcom 4321 support
On Friday 27 February 2009 20:28:36 Andres Aguirre wrote: > Ok, So the info in http://wpkg.org/Running_Debian_on_ASUS_WL-500W is incorrect http://xkcd.com/386/ SCNR :) -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] uclibc-0.9.30 compilation fails
/develop/svn/openwrt_wap54g/trunk/staging_dir/toolchain-mipsel_gcc-4.3.3_uClibc-0.9.30/info.mk /home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/host/bin/sed -i -e 's,^\(LIBC_VERSION\)=.*,\1=0.9.30,' /home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/toolchain-mipsel_gcc-4.3.3_uClibc-0.9.30/info.mk /home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/host/bin/sed -i -e 's,^\(LIBC_PATCHVER\)=.*,\1=,' /home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/toolchain-mipsel_gcc-4.3.3_uClibc-0.9.30/info.mk prepare uClibc version 0.9.30 bzcat /home/mb/develop/svn/openwrt_dl/uClibc-0.9.30.tar.bz2 | /bin/tar -C /home/mb/develop/svn/openwrt_wap54g/trunk/build_dir/toolchain-mipsel_gcc-4.3.3_uClibc-0.9.30/uClibc-0.9.30/.. -xf - Applying ./patches-0.9.30/110-compat_macros.patch using plaintext: patching file include/string.h Applying ./patches-0.9.30/120-adjtimex.patch using plaintext: patching file include/sys/timex.h Hunk #1 succeeded at 116 with fuzz 1. Applying ./patches-0.9.30/130-sockets_throw.patch using plaintext: patching file libc/sysdeps/linux/mips/bits/socket.h Hunk #1 FAILED at 269. 1 out of 1 hunk FAILED -- saving rejects to file libc/sysdeps/linux/mips/bits/socket.h.rej Patch failed! Please fix ./patches-0.9.30/130-sockets_throw.patch! make[3]: *** [/home/mb/develop/svn/openwrt_wap54g/trunk/build_dir/toolchain-mipsel_gcc-4.3.3_uClibc-0.9.30/uClibc-0.9.30/.prepareda7863fa5905298a1f0c5dda1163671a2] Error 1 make[3]: Leaving directory `/home/mb/develop/svn/openwrt_wap54g/trunk/toolchain/uClibc' make[2]: *** [toolchain/uClibc/prepare] Error 2 make[2]: Leaving directory `/home/mb/develop/svn/openwrt_wap54g/trunk' make[1]: *** [/home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/target-mipsel_uClibc-0.9.30/stamp/.toolchain_install] Error 2 make[1]: Leaving directory `/home/mb/develop/svn/openwrt_wap54g/trunk' make: *** [world] Error 2 -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] uclibc-0.9.30 compilation fails
On Sunday 29 March 2009 15:01:35 Luigi Mantellini wrote: > The patches are for uClibc 0.9.30.1. Change your .config adding: > > CONFIG_UCLIBC_EXTRA_VERSION=".1" Now libnl fails. make[3]: Entering directory `/home/mb/develop/svn/openwrt_wap54g/trunk/package/libnl' WARNING: skipping libnl -- package not selected CFLAGS="-Os -pipe -mips32 -mtune=mips32 -funit-at-a-time -fhonour-copts -ffunction-sections -fpic -I/home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/target-mipsel_uClibc-0.9.30/usr/include -I/home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/target-mipsel_uClibc-0.9.30/include " CXXFLAGS="-Os -pipe -mips32 -mtune=mips32 -funit-at-a-time -fhonour-copts -ffunction-sections -fpic -I/home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/target-mipsel_uClibc-0.9.30/usr/include -I/home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/target-mipsel_uClibc-0.9.30/include " LDFLAGS="-L/home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/toolchain-mipsel_gcc-4.3.3_uClibc-0.9.30/usr/lib -L/home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/toolchain-mipsel_gcc-4.3.3_uClibc-0.9.30/lib -L/home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/target-mipsel_uClibc-0.9.30/usr/lib -L/home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/target-mipsel_uClibc-0.9.30/lib " make -C /home /mb/develop/svn/openwrt_wap54g/trunk/build_dir/target-mipsel_uClibc-0.9.30/libnl-1.1/. AR=mipsel-openwrt-linux-uclibc-ar AS="mipsel-openwrt-linux-uclibc-gcc -c -Os -pipe -mips32 -mtune=mips32 -funit-at-a-time -fhonour-copts" LD=mipsel-openwrt-linux-uclibc-ld NM=mipsel-openwrt-linux-uclibc-nm CC="mipsel-openwrt-linux-uclibc-gcc" GCC="mipsel-openwrt-linux-uclibc-gcc" CXX="mipsel-openwrt-linux-uclibc-g++" RANLIB=mipsel-openwrt-linux-uclibc-ranlib STRIP=mipsel-openwrt-linux-uclibc-strip OBJCOPY=mipsel-openwrt-linux-uclibc-objcopy OBJDUMP=mipsel-openwrt-linux-uclibc-objdump SIZE=mipsel-openwrt-linux-uclibc-size CROSS="mipsel-openwrt-linux-uclibc-" ARCH="mipsel" ; make[4]: Entering directory `/home/mb/develop/svn/openwrt_wap54g/trunk/build_dir/target-mipsel_uClibc-0.9.30/libnl-1.1' Entering lib MAKE libnl.so.1.1 LD libnl.so.1.1 LN libnl.so.1.1 libnl.so.1 LN libnl.so.1 libnl.so make[6]: `libnl.a' is up to date. Entering include Entering doc Entering src LD nl-addr-add /home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/toolchain-mipsel_gcc-4.3.3_uClibc-0.9.30/usr/lib/gcc/mipsel-openwrt-linux-uclibc/4.3.3/../../../../mipsel-openwrt-linux-uclibc/bin/ld: nl-addr-add: hidden symbol `__clz_tab' in /home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/toolchain-mipsel_gcc-4.3.3_uClibc-0.9.30/usr/lib/gcc/mipsel-openwrt-linux-uclibc/4.3.3/libgcc.a(_clz.o) is referenced by DSO /home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/toolchain-mipsel_gcc-4.3.3_uClibc-0.9.30/usr/lib/gcc/mipsel-openwrt-linux-uclibc/4.3.3/../../../../mipsel-openwrt-linux-uclibc/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[5]: *** [nl-addr-add] Error 1 make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/mb/develop/svn/openwrt_wap54g/trunk/build_dir/target-mipsel_uClibc-0.9.30/libnl-1.1' make[3]: *** [/home/mb/develop/svn/openwrt_wap54g/trunk/build_dir/target-mipsel_uClibc-0.9.30/libnl-1.1/.built] Error 2 make[3]: Leaving directory `/home/mb/develop/svn/openwrt_wap54g/trunk/package/libnl' make[2]: *** [package/libnl/compile] Error 2 make[2]: Leaving directory `/home/mb/develop/svn/openwrt_wap54g/trunk' make[1]: *** [/home/mb/develop/svn/openwrt_wap54g/trunk/staging_dir/target-mipsel_uClibc-0.9.30/stamp/.package_compile] Error 2 make[1]: Leaving directory `/home/mb/develop/svn/openwrt_wap54g/trunk' make: *** [world] Error 2 -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
On Sunday 07 June 2009 11:28:50 matthieu castet wrote: > Hi, > > I wonder with openwrt for bcm47xx is not build with "-msoft-float". > The cpu doesn't have fpu and the current floating code get emulated by the > kernel emulator instead of using the gcc emulation support (that is cheaper > because there is no kernel trap). Well, I guess on a typical bcm47xx setup there's hardly any application that uses floating point math. Does -msoft-float increase the binary/image size? If so, I'd vote for _not_ adding -msoft-float. If it doesn't make a size difference, we should probably add it. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
On Monday 08 June 2009 21:35:05 matthieu castet wrote: > Michael Buesch wrote: > > On Sunday 07 June 2009 11:28:50 matthieu castet wrote: > >> Hi, > >> > >> I wonder with openwrt for bcm47xx is not build with "-msoft-float". > >> The cpu doesn't have fpu and the current floating code get emulated by the > >> kernel emulator instead of using the gcc emulation support (that is cheaper > >> because there is no kernel trap). > > > > Well, I guess on a typical bcm47xx setup there's hardly any application > > that uses > > floating point math. > note that dropbear seems to use some, but that not critical. > > > Does -msoft-float increase the binary/image size? If so, I'd > > vote for _not_ adding -msoft-float. If it doesn't make a size difference, > > we should > > probably add it. > > > That shouldn't increase size of application that don't use float. > I did a quick test with dropbear that contain very few float. > Here are the results (sfloat means -msoft-float, sgcc mean -shared-libgcc) > > > $size /tmp/dropbear* > textdata bss dec hex filename > 22692442521744 232920 38dd8 /tmp/dropbear > 23471943281744 240791 3ac97 /tmp/dropbear_sfloat > 22078141921744 226717 3759d /tmp/dropbear_sfloat_sgcc > 21995641521744 225852 3723c /tmp/dropbear_sgcc > > As you can see with a static libgcc the size of the softfloat binary > increase (8k) because all float emulation code is duplicated in the binary. > With a shared libgcc the softfloat binary is smaller, the increase size > is less than 1k. > > I don't know the impact for whole binary. I should try to build a > typical bcm47xx setup and see the impact. Ok. It still smells like we're trying to solve a problem that does not exist. Is the performance of any app increased in real life? -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Getting brcm47xx run on WAP54g (2 MB flash)
On Monday 15 June 2009 12:58:18 Ferenc Wagner wrote: > Bastian Bittorf writes: > > > * Ferenc Wagner [14.06.2009 14:45]: > > > >> Why is that ifconfig there at all? > > > > because I didn't found the time till now, to make a function > > ifconfig() which is made known @common_func and translates the known > > calls to 'ip'. Give me some weeks and i will send a patch to discard > > 'ifconfig' ... (i promised this at WCW2009...) > > Heh, I meant what its purpose was, not why it isn't an ip command > instead. :) Btw. ifconfig up started to spit out a page allocation > failure (attached at the end of this mail) but seems to work otherwise > OK... > > >> what I understand from it). For my purposes using a region with > >> smaller blocks for jffs2 would be a big gain, as currently I've got a > >> single 64 KB erase block for it, which obviously does not fly. Is it > >> really possible? > > > > AFAIK the blocksize is fixed/hardlocked for this flashchip to 64k. > > Ever played with 'printk-patch' or similar things the get a smaller kernel? > > Not yet. But would that by me another 64k? I don't think so... By > optimising the kernel for size I'm at 4 (!) erase blocks now, so I'd > need one more to get an operating jffs2. But this agains gives me the > feeling that jffs2 is rather inefficient at using flash space: I need > 384k to store a single byte! :/ I wonder how much more I could store > there in this case... I am running a OpenWRT with a 2.6 kernel on a WAP54G. It's rather difficult to get it stripped down, but it _does_ work. The device does run in production since several months. So what are the issues? It turns out RAM is _not_ an issue. Just disable all services that are not absolutely required (dhcp, etc...) and you'll get enough free RAM. The issue is flash. In fact the 5 erase blocks are the issue. First start with disabling _everything_ that is not needed to keep the device alife. In the kernel and in the openwrt config (busybox config, too). The second step is to search for big flash consumers. It turns out the crypto modules do consume a large amount of flash. Even if the functionality is already compiled into the kernel image itself. Attached is a patch which strips down several hundred kiB of flash space. I think it doesn't apply anymore to current trunk, but you might get the idea. Another rather big flash consumer is the b43 driver firmware. There's an option in openwrt config to include only the necessary firmware files. Use it. I'm not sure if this is any useful for you running a 2.4 image, but I just wanted to drop it into the discussion. Have fun! Index: target/linux/brcm47xx/config-2.6.28 === --- target/linux/brcm47xx/config-2.6.28 (revision 15160) +++ target/linux/brcm47xx/config-2.6.28 (working copy) @@ -1,6 +1,6 @@ CONFIG_32BIT=y # CONFIG_64BIT is not set -# CONFIG_8139TOO is not set +# CONFIG_AIO is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y @@ -9,14 +9,13 @@ CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ARPD is not set CONFIG_B44=y -CONFIG_B44_PCI=y -CONFIG_B44_PCICORE_AUTOSELECT=y -CONFIG_B44_PCI_AUTOSELECT=y -CONFIG_BASE_SMALL=0 +# CONFIG_BASE_FULL is not set +CONFIG_BASE_SMALL=1 CONFIG_BCM47XX=y CONFIG_BITREVERSE=y -# CONFIG_BSD_DISKLABEL is not set +# CONFIG_BLK_DEV_INITRD is not set # CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_BUG is not set CONFIG_CEVT_R4K=y CONFIG_CFE=y CONFIG_CLASSIC_RCU=y @@ -52,14 +51,32 @@ # CONFIG_CPU_TX39XX is not set # CONFIG_CPU_TX49XX is not set # CONFIG_CPU_VR41XX is not set +CONFIG_CRYPTO_AEAD2=y +CONFIG_CRYPTO_AES=y +CONFIG_CRYPTO_ALGAPI=y +CONFIG_CRYPTO_ALGAPI2=y +CONFIG_CRYPTO_ARC4=y +CONFIG_CRYPTO_BLKCIPHER=y +CONFIG_CRYPTO_BLKCIPHER2=y +CONFIG_CRYPTO_ECB=y +CONFIG_CRYPTO_HASH2=y +CONFIG_CRYPTO_MANAGER=y +CONFIG_CRYPTO_MANAGER2=y +CONFIG_CRYPTO_RNG2=y CONFIG_CSRC_R4K=y -CONFIG_DEVPORT=y +# CONFIG_DEBUG_FS is not set +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_IOSCHED="noop" +CONFIG_DEFAULT_NOOP=y +CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_DM9000 is not set CONFIG_DMA_NEED_PCI_MAP_STATE=y CONFIG_DMA_NONCOHERENT=y CONFIG_EARLY_PRINTK=y -# CONFIG_FIXED_PHY is not set +# CONFIG_EPOLL is not set +# CONFIG_EVENTFD is not set # CONFIG_FREEZER is not set +# CONFIG_FUTEX is not set CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CMOS_UPDATE=y @@ -76,8 +93,9 @@ # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_HAVE_IDE=y CONFIG_HAVE_OPROFILE=y +# CONFIG_HIGH_RES_TIMERS is not set CONFIG_HW_HAS_PCI=y -CONFIG_HW_RANDOM=y +# CONFIG_HW_RANDOM is not set CONFIG_HZ=250 # CONFIG_HZ_100 is not set CONFIG_HZ_250=y @@ -86,18 +104,29 @@ # CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set # CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set # CONFIG_IDE is not set -CONFIG_INITRAMFS_SOURCE="" -CONFIG_INPUT=y -CONFIG_INPUT_EVDEV=y -CONFIG_INPU
Re: [OpenWrt-Devel] Getting brcm47xx run on WAP54g (2 MB flash)
On Tuesday 16 June 2009 11:55:59 Ferenc Wagner wrote: > Thanks, that's good to know! Don't you feel like putting this into > the Wiki and linking it from the WAP54g page from WiP? :) Ah well. The WAP is officially not supported. But there's not that much to write about it anyway. Just disable anything that's not required. ;) > Thanks for reminding me of BusyBox. The menuconfig interface hides > that submenu, like, completely! Yeah, read those options carefully. There are also a few options that need to be enabled to safe space (space-time-tradeoff options) > > The second step is to search for big flash consumers. It turns out > > the crypto modules do consume a large amount of flash. Even if the > > functionality is already compiled into the kernel image itself. > > Which of them are really needed, btw? This only applies to 2.6 kernel. The crypto modules needed by mac80211 are only required. I compiled them into the image. That saves some space. In general, compile as much as possible into the kernel and avoid modules. > > Attached is a patch which strips down several hundred kiB of flash > > space. I think it doesn't apply anymore to current trunk, but you > > might get the idea. > > Yes, I was experimenting with things like this. But there's some > more to do, as it seems. Yeah this stuff was changed recently. There might be more. > > Another rather big flash consumer is the b43 driver firmware. > > There's an option in openwrt config to include only the necessary > > firmware files. Use it. > > Yes, that's pretty important. I've found it already. And did you try > optimising your kernel for size (CONFIG_CC_OPTIMIZE_FOR_SIZE)? Yeah sure. > > I'm not sure if this is any useful for you running a 2.4 image, but > > I just wanted to drop it into the discussion. Have fun! > > No, I'm running 2.6, so this was immensely useful. Thank you very > much! A question, though: after you managed to get your 5th erase > block and had a working jff2, did you actually use it for anything > else than setting up a couple of variables, like eg. operating mode > and IP addresses? Just for the net config. There's really no service running on the device (not even syslogd, klogd, etc...), so there's really nothing else to config. ;) > Because if not, then I think a startup/shutdown script pair, which > translated between nvram variables and /etc/config, could work just as > well, without requiring us to squeeze things this bad. Yes sure. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
On Friday 19 June 2009 18:20:53 Florian Fainelli wrote: > Le Tuesday 09 June 2009 16:00:47 Michael Buesch, vous avez écrit : > > On Monday 08 June 2009 21:35:05 matthieu castet wrote: > > > Michael Buesch wrote: > > > > On Sunday 07 June 2009 11:28:50 matthieu castet wrote: > > > >> Hi, > > > >> > > > >> I wonder with openwrt for bcm47xx is not build with "-msoft-float". > > > >> The cpu doesn't have fpu and the current floating code get emulated by > > > >> the kernel emulator instead of using the gcc emulation support (that > > > >> is cheaper because there is no kernel trap). > > > > > > > > Well, I guess on a typical bcm47xx setup there's hardly any application > > > > that uses floating point math. > > > > > > note that dropbear seems to use some, but that not critical. > > > > > > > Does -msoft-float increase the binary/image size? If so, I'd > > > > vote for _not_ adding -msoft-float. If it doesn't make a size > > > > difference, we should probably add it. > > > > > > That shouldn't increase size of application that don't use float. > > > I did a quick test with dropbear that contain very few float. > > > Here are the results (sfloat means -msoft-float, sgcc mean > > > -shared-libgcc) > > > > > > > > > $size /tmp/dropbear* > > > textdata bss dec hex filename > > > 22692442521744 232920 38dd8 /tmp/dropbear > > > 23471943281744 240791 3ac97 /tmp/dropbear_sfloat > > > 22078141921744 226717 3759d /tmp/dropbear_sfloat_sgcc > > > 21995641521744 225852 3723c /tmp/dropbear_sgcc > > > > > > As you can see with a static libgcc the size of the softfloat binary > > > increase (8k) because all float emulation code is duplicated in the > > > binary. With a shared libgcc the softfloat binary is smaller, the > > > increase size is less than 1k. > > > > > > I don't know the impact for whole binary. I should try to build a > > > typical bcm47xx setup and see the impact. > > > > Ok. It still smells like we're trying to solve a problem that does not > > exist. Is the performance of any app increased in real life? > > We can still allow soft-float to be used in the toolchain, and keep the > in-kernel FPU emulator for compatibility, but then we will loose some space. Yeah well. That's my question. Do we actually gain performance or do we only loose some space? If we do _not_ gain performance, it certainly is not a good idea to waste space. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
On Saturday 20 June 2009 00:09:56 Jonas Gorski wrote: > > If we do _not_ gain performance, it certainly is not a good idea to waste > > space. > > I would be very surprised if we wouldn't. Every kernel emulated > floating point operation results in an exception and the appropriate > handling (fpu emulation is ugly), while soft-float should stay > completely in user space. > > Also, the mips fpu emulator itself suggests that. > Quoting linux/arch/mips/math-emu/cp1emu.c: > > * Note if you know that you won't have an fpu, then you'll get much > > * better performance by compiling with -msoft-float! > > To get some numbers: Perhaps could somebody test with 'sample' from > libmpcdec the difference in speed between in-kernel emulation and > soft-float? https://dev.openwrt.org/ticket/4715 suggests that the > library depends heavily on floating point when not using fixed point > math. No you completely got me wrong. I am talking about the performance gain in real life. userspace soft float certainly _is_ faster than kernel float. But _if_ userspace soft float is bigger in size than kernel float, it probably is not worth the space tradeoff, because floating point is hardly used on a router. Did somebody test this: * Image with kernel FP emu disabled and userspace softemu enabled. * Image with kernel FP emu enabled and userspace softemu disabled. Which one is smaller? -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
On Saturday 20 June 2009 23:56:51 Jonas Gorski wrote: > 2009/6/20 Michael Buesch : > > On Saturday 20 June 2009 00:09:56 Jonas Gorski wrote: > >> > If we do _not_ gain performance, it certainly is not a good idea to > >> > waste space. > >> > >> I would be very surprised if we wouldn't. Every kernel emulated > >> floating point operation results in an exception and the appropriate > >> handling (fpu emulation is ugly), while soft-float should stay > >> completely in user space. > >> > >> Also, the mips fpu emulator itself suggests that. > >> Quoting linux/arch/mips/math-emu/cp1emu.c: > >> > * Note if you know that you won't have an fpu, then you'll get much > >> > * better performance by compiling with -msoft-float! > >> > >> To get some numbers: Perhaps could somebody test with 'sample' from > >> libmpcdec the difference in speed between in-kernel emulation and > >> soft-float? https://dev.openwrt.org/ticket/4715 suggests that the > >> library depends heavily on floating point when not using fixed point > >> math. > > > > No you completely got me wrong. I am talking about the performance gain in > > real life. > > userspace soft float certainly _is_ faster than kernel float. But _if_ > > userspace > > soft float is bigger in size than kernel float, it probably is not worth > > the space tradeoff, > > because floating point is hardly used on a router. > > I apology, I really did misunderstand you. > > > Did somebody test this: > > * Image with kernel FP emu disabled and userspace softemu enabled. > > * Image with kernel FP emu enabled and userspace softemu disabled. > > > > Which one is smaller? > > Disabling the kernel fpu emu isn't intended in linux, so I had to hack > the emulation away, mainly by removing any fpu references in > arch/mips/kernel/ until it compiled. > I don't know if it really works, I don't have a second device for testing. > > I used the brcm47xx/default profile for testing, making distclean > before compiling. > > With kernel-fpuemu and no softfloat: > 256 openwrt-brcm47xx-squashfs.trx > Without fpuemu and with softfloat: > 2625536 openwrt-brcm47xx-squashfs.trx > > So the image with soft-float instead of the in-kernel fpu emulation > uses one block more. For me this would be an acceptable increase. So what about the following. We introduce another option in the kernel config to disable fpuemu. This way the user can select either useremu, kernelemu or no emu at all. This probably is a win-win situation then. Because if I do care about space, I can turn off _both_ emulators. And you, who do care about performance, can set the openwrt default to kernelemu-off useremu-on. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to extract the quilt kernel patches?
On Sunday 21 June 2009 15:46:14 Jo-Philipp Wich wrote:
> Hi.
>
> Usually you can do it this way:
>
> make target/linux/{clean,prepare} QUILT=1
>
> Optionally you can override LINUX_VERSION with a desired target version.
>
> After that a kernel source tree with quilt series is prepared in
> build_dir/linux-/linux-/ .
>
> You can add / modify / remove your patches there. After you finished and
> refreshed the stuff, you should copy the modified patches from
> build_dir/linux-/linux-/patches/... to:
>
> - target/linux//patches-
> for target specific patches
>
> or
>
> - target/linux/generic-2.[46]/patches-
> for generic patches that affect all platforms.
make target/linux-update
does that copying for you.
> Finally rebuild the kernel normally with
> make target/linux/{clean,compile} .
I think it's target/linux-{clean,compile}
--
Greetings, Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] SSB USB - work around for silicon error in bcm5354 usb20 core
On Sunday 16 August 2009 17:23:40 Steve Brown wrote: > Found in the Asus GPL sources. > > This is very noticable with a Seagate FreeAgent drive. Without the patch, > long writes give a "reset high speed usb" error and hang until > the drive is disconnnected. The patch solves that problem. > > Steve Thanks. Do your patches also apply to the upstream ssb usb driver, or is there too much stuff sitting in openwrt which is not mainline? -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] SSB USB - work around for silicon error in bcm5354 usb20 core
On Sunday 16 August 2009 17:23:40 Steve Brown wrote: > Found in the Asus GPL sources. > > This is very noticable with a Seagate FreeAgent drive. Without the patch, > long writes give a "reset high speed usb" error and hang until > the drive is disconnnected. The patch solves that problem. > > Steve > > > I applied this patch. Thanks a lot. But I don't understand the second "allow building ohci driver without also building ehci" patch. Doesn't that trade one failure for another? If CONFIG_USB_EHCI_HCD_SSB, the functions won't be available. And as far as I can see CONFIG_USB_EHCI_HCD does not imply CONFIG_USB_EHCI_HCD_SSB. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] SSB USB - work around for silicon error in bcm5354 usb20 core
On Monday 07 September 2009 15:23:59 Steve Brown wrote: > Michael Buesch wrote: > > On Sunday 16 August 2009 17:23:40 Steve Brown wrote: > > > >> Found in the Asus GPL sources. > >> > >> This is very noticable with a Seagate FreeAgent drive. Without the patch, > >> long writes give a "reset high speed usb" error and hang until > >> the drive is disconnnected. The patch solves that problem. > >> > >> Steve > >> > >> > >> > >> > > > > I applied this patch. Thanks a lot. > > > > But I don't understand the second "allow building ohci driver without also > > building ehci" > > patch. Doesn't that trade one failure for another? If > > CONFIG_USB_EHCI_HCD_SSB, the functions > > won't be available. And as far as I can see CONFIG_USB_EHCI_HCD does not > > imply CONFIG_USB_EHCI_HCD_SSB. > > > > > You are correct. The patch is incomplete. It needs to depend on both > CONFIG_USB_EHCI_HCD and CONFIG_USB_EHCI_HCD_SSB. I'll fix it and resubmit. > > I found this while looking at a problem w/ the ohci driver and a > prolific rs232 dongle. I tried to build only the ohci driver and it > failed. The problem is that CONFIG_USB_EHCI_HCD_SSB is set by default in > brcm47xx's config-2.6.xx. So, even if you build without the ehci driver, > the calls to the ehci driver in the ohci driver are still compiled in > and the ohci driver fails to load. Can you check if this is still true after my commit #17536? -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Regarding "make all / make install" usage
On Tuesday 27 October 2009 12:26:00 Felix Fietkau wrote: > To be honest, I don't see this as a problem. We don't pass parallel > builds on to individual package make processes. Parallelization is done > *only* on the build system level, with one exception: the kernel. > And since most packages don't handle parallel builds properly anyway, I > don't see much of a reason to change this I think you are overestimating the issue with your "most packages" statement. I have the following in my bashrc since more than 3 years alias make="make -j5" and I did not see a single parallelization related failure, yet. Yeah, I also saw some gcc toolchain failures in the past (over 5 years ago) and I did not try parallel build on gcc again since then. Maybe that's an exception. So wouldn't it be better to allow parallel builds in the packages and instead disable it _only_ for broken packages? That would be a huge advantage and speedup the openwrt buildprocess by about 35-40 percent points on my quad machine. The advantage gets higher the more cores we have. And I think quads are not that uncommon anymore today. I do believe that compilation time is a major factor of development efficiency. http://xkcd.com/303/ -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Regarding "make all / make install" usage
On Wednesday 28 October 2009 03:04:41 Felix Fietkau wrote: > > That would be a huge advantage and speedup the openwrt buildprocess by > > about 35-40 percent points on my quad machine. The advantage gets higher > > the more cores we have. > > And I think quads are not that uncommon anymore today. > Why do you think the difference is that big between building multiple > packages at the same time and building individual packages in parallel? Because the cpu utilization is horribly low during an openwrt build. It ranges from 25% for the toolchain to 99% for the kernel. For compiling "normal" packages there's usually an overall utilization of 60-75%. I'm pretty sure if we'd allow two processors (or more) on one package at the same time, it would go up to nearly 99% on my machine. Especially for bigger packages like busybox, ssh, etc... I'd also like to have an optional (default off) parallel build of the toolchain. I don't mind poking it two or three times. That'd still be faster than compiling the whole toolchain at 25%. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Regarding "make all / make install" usage
On Wednesday 28 October 2009 21:29:10 Felix Fietkau wrote: > Michael Buesch wrote: > > On Wednesday 28 October 2009 03:04:41 Felix Fietkau wrote: > >> > That would be a huge advantage and speedup the openwrt buildprocess by > >> > about 35-40 percent points on my quad machine. The advantage gets higher > >> > the more cores we have. > >> > And I think quads are not that uncommon anymore today. > >> Why do you think the difference is that big between building multiple > >> packages at the same time and building individual packages in parallel? > > > > Because the cpu utilization is horribly low during an openwrt build. > > It ranges from 25% for the toolchain to 99% for the kernel. > > For compiling "normal" packages there's usually an overall utilization of > > 60-75%. I'm pretty sure > > if we'd allow two processors (or more) on one package at the same time, it > > would go up to nearly 99% > > on my machine. Especially for bigger packages like busybox, ssh, etc... > > I'd also like to have an optional (default off) parallel build of the > > toolchain. I don't mind > > poking it two or three times. That'd still be faster than compiling the > > whole toolchain at 25%. > I did a test with all packages of trunk selected (/packages not > included), and 3 packages broke with very weird build failures. > This was with a small change to include/package.mk that sets > MAKE := $(MAKE) -j 8 > and some other patches to replace $(MAKE) all install calls with > multiple calls. > The three packages that broke were apex, iproute2, openssl. Also when > I've done similar tests in the past, some other packages also broke, > though only under rare, hard to trigger circumstances. > If somebody makes a patch that enables package build parallelization, I > definitely don't want to have this enabled by default whenever somebody > does make -j in the OpenWrt build system. > I think most people that use make -j would prefer to have something that > may be a little slower, but doesn't cause unexpected build failures > depending on the parallelization level. Yeah. I'm fine with an option that defaults to off and has a big warning message. However, I don't know the buildsystem good enough to add such an option and proper parallelization... -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Regarding "make all / make install" usage
On Wednesday 28 October 2009 22:09:47 Felix Fietkau wrote: > Another way would be to add a configurable parallelization level for > individual package make processes, which results in a similar override > as the one I used for testing. I think that's good enough for starters. The process scheduler will do its job then... On a machine with enough RAM one would just manually pass -j$(NR_OF_CPUS) to the packages make. At least it will improve the situation. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] libdirectfb fails to download
make[3]: Entering directory `/home/mb/develop/svn/openwrt_wl500gv2/trunk/feeds/packages/libs/libdirectfb' mkdir -p /home/mb/develop/svn/openwrt_dl /home/mb/develop/svn/openwrt_wl500gv2/trunk/scripts/download.pl "/home/mb/develop/svn/openwrt_dl" "DirectFB-1.4.2.tar.gz" "unknown" http://www.directfb.org/downloads/Core/DirectFB-1.4 --2009-12-15 19:06:53-- http://www.directfb.org/downloads/Core/DirectFB-1.4/DirectFB-1.4.2.tar.gz Resolving www.directfb.org... 212.227.87.76 Connecting to www.directfb.org|212.227.87.76|:80... failed: Connection timed out. Retrying. --2009-12-15 19:07:14-- (try: 2) http://www.directfb.org/downloads/Core/DirectFB-1.4/DirectFB-1.4.2.tar.gz Connecting to www.directfb.org|212.227.87.76|:80... failed: Connection timed out. Retrying. --2009-12-15 19:07:36-- (try: 3) http://www.directfb.org/downloads/Core/DirectFB-1.4/DirectFB-1.4.2.tar.gz Connecting to www.directfb.org|212.227.87.76|:80... failed: Connection timed out. Retrying. --2009-12-15 19:07:59-- (try: 4) http://www.directfb.org/downloads/Core/DirectFB-1.4/DirectFB-1.4.2.tar.gz Connecting to www.directfb.org|212.227.87.76|:80... failed: Connection timed out. Retrying. --2009-12-15 19:08:23-- (try: 5) http://www.directfb.org/downloads/Core/DirectFB-1.4/DirectFB-1.4.2.tar.gz Connecting to www.directfb.org|212.227.87.76|:80... failed: Connection timed out. Giving up. Download failed. --2009-12-15 19:08:43-- http://mirror2.openwrt.org/sources/DirectFB-1.4.2.tar.gz Resolving mirror2.openwrt.org... 88.198.39.176 Connecting to mirror2.openwrt.org|88.198.39.176|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2009-12-15 19:08:43 ERROR 404: Not Found. Download failed. --2009-12-15 19:08:43-- http://downloads.openwrt.org/sources/DirectFB-1.4.2.tar.gz Resolving downloads.openwrt.org... 78.24.191.177 Connecting to downloads.openwrt.org|78.24.191.177|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2009-12-15 19:08:44 ERROR 404: Not Found. Download failed. No more mirrors to try - giving up. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] libdirectfb fails to download
On Tuesday 15 December 2009 21:44:06 Russell Senior wrote: > > Google found me this: > > http://ftp.osuosl.org/pub/nslu2/sources/DirectFB-1.4.2.tar.gz Yeah I also found it. Thanks. So can somebody upload it to the openwrt mirror? Or should we just (temporarly) change the download URL in the package? -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] 2.6.30+: BCM5354 USB LOCKUP (ehci-ssb) due to missed kernel changes
On Tuesday 22 December 2009 22:29:32 Andreas Mohr wrote: > Now that this annoying issue is out of the way, how to go forward? By sending a patch? > And I would be very pleased if ehci-ssb.c could find its way into mainline > pretty soon, Yeah. Care to do so? -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Commits] r18935 - in trunk/package/mac80211: . files/host_bin
On Saturday 26 December 2009 02:06:36 openwrt-comm...@openwrt.org wrote: > Author: hauke > Date: 2009-12-26 02:06:36 +0100 (Sat, 26 Dec 2009) > New Revision: 18935 > > Modified: >trunk/package/mac80211/Config.in.b43 >trunk/package/mac80211/files/host_bin/b43-fwsquash.py > Log: > [mac80211] b43: Add L-PHY firemware files to squash script > > Use firmware 4.178.10.4 as default on. > Select firmware for all supported phy types and version as default. > > Close ticket #5978 > @@ -65,7 +66,7 @@ > config B43_FW_SQUASH_PHYTYPES > string "PHY types to include" > depends on PACKAGE_kmod-b43 && B43_FW_SQUASH > - default "G,LP,N" > + default "A,AG,G,LP" Well, why remove N and add A? They are both unsupported. :) > Modified: trunk/package/mac80211/files/host_bin/b43-fwsquash.py > === > --- trunk/package/mac80211/files/host_bin/b43-fwsquash.py 2009-12-26 > 00:23:35 UTC (rev 18934) > +++ trunk/package/mac80211/files/host_bin/b43-fwsquash.py 2009-12-26 > 01:06:36 UTC (rev 18935) > @@ -65,7 +65,8 @@ > "ucode5.fw" : (5,6,7,8,9,10,), > "ucode11.fw": (11,12,), > "ucode13.fw": (13,), > - "pcm4.fw" : (1,2,3,4,), > + "ucode14.fw": (14,), > + "ucode15.fw": (15,), > "pcm5.fw" : (5,6,7,8,9,10,), > } Why do we remove pcm4? -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Commits] r18935 - in tru nk/package/mac80211: . files/host_bin
On Saturday 26 December 2009 16:58:51 Hauke Mehrtens wrote: > > Why do we remove pcm4? > pcm4.fw is never loaded by the b43 driver. There is no reverence to this > file in the driver source and the new fwcutter version does not extract > it any more out of the firmware for b43 driver. Why should it still be > in this list, if there is no way to load it? Well, whether it is in this _list_ does not affect whether it's in the _image_ or not. The pcm4 won't appear in the image, unless you also specify core revs <=4 in the config. Currently only revs >=5 are the default config. > It makes only sense when > using the b43-fwsquash.py script also for b43legacy. Yeah. Exactly. I think there might be people that also want to use squashing for b43legacy, especially because these devices tend to have very small flash. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] brcm 47xx 2.6.32 update patch
On Thursday 07 January 2010 04:25:20 puchu wrote: > maybe someone knows a way to fix this I will commit the patch without the modification to LINUX_VERSION in the makefile. So we can debug that problem separately. Basic .32 support is a good idea anyway. Thanks for the patch. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Migrate mmc_over_gpio configuration to UCI
On Saturday 22 March 2008 11:48:21 [EMAIL PROTECTED] wrote: > Here is my first attemt to migrate the configuration for the new MMC driver > (for Kernel 2.6) to UCI. Cool, thanks a lot. :) > With this patch you can configure mmc_over_gpio via UCI > (/etc/config/mmc_over_gpio). > If you have done this you can use /etc/config/fstab to mount the partitions > from the card or configure swap. > > Please test the patch and report. I don't like that gpiomask. Why is it needed? It's difficult for users to calculate it. So we need to calculate that automatically, or remove the need to have it. Though, calculating bitmasks might not be that easy in the shell. But I think it should be possible, if we use some precalculated tables and stuff. In any case, requireing the user to do the calculation is the wrong thing IMO. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Migrate mmc_over_gpio configuration to UCI
On Saturday 22 March 2008 14:37:10 [EMAIL PROTECTED] wrote: > > I don't like that gpiomask. > > Why is it needed? It's difficult for users to calculate it. > > So we need to calculate that automatically, or remove the need to have it. > > Though, calculating bitmasks might not be that easy in the shell. But I > > think > > it should be possible, if we use some precalculated tables and stuff. > > In any case, requireing the user to do the calculation is the wrong thing > > IMO. > I also don't like the manual gpiomask calculation. It's too difficult for > most users. > > I think gpiomask is still required and without the driver isn't working for > me (tested on WRT54GL). > Though, I don't remember exactly what gpiomask is used for but maybe nbd or > [mbm] can explain it once more for us. Hm, sounds like diag will override the GPIO settings. It should work without this mask (and in fact does for me), as the mmc-over-gpio driver does properly set the required configuration to the GPIO pins through the lowlevel GPIO functions. It does also request this GPIO line, however, on SSB the request still is a NOP, so it's possible for two drivers accessing a GPIO line at the same time. So I guess diag simply does poke with some GPIO line that we need. Additionally, the GPIO-mask is not really a per-mmc-card option, but it is stored per-mmc-card in the config. It really is a _global_ option. So if you have two MMC cards (which is theoretically possible, if you have enough GPIO lines), you'd need _one_ global gpiomask that holds the bits of both card's GPIO lines. In the end, I think we first need to figure out what the gpiomask in diag really does. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Migrate mmc_over_gpio configuration to UCI
On Saturday 22 March 2008 14:45:15 Michael Buesch wrote: > On Saturday 22 March 2008 14:37:10 [EMAIL PROTECTED] wrote: > > > I don't like that gpiomask. > > > Why is it needed? It's difficult for users to calculate it. > > > So we need to calculate that automatically, or remove the need to have it. > > > Though, calculating bitmasks might not be that easy in the shell. But I > > > think > > > it should be possible, if we use some precalculated tables and stuff. > > > In any case, requireing the user to do the calculation is the wrong thing > > > IMO. > > I also don't like the manual gpiomask calculation. It's too difficult for > > most users. > > > > I think gpiomask is still required and without the driver isn't working for > > me (tested on WRT54GL). > > Though, I don't remember exactly what gpiomask is used for but maybe nbd or > > [mbm] can explain it once more for us. > > Hm, sounds like diag will override the GPIO settings. > It should work without this mask (and in fact does for me), > as the mmc-over-gpio driver does properly set the required configuration > to the GPIO pins through the lowlevel GPIO functions. > It does also request this GPIO line, however, on SSB the request still is a > NOP, > so it's possible for two drivers accessing a GPIO line at the same time. > So I guess diag simply does poke with some GPIO line that we need. > > Additionally, the GPIO-mask is not really a per-mmc-card option, but it is > stored per-mmc-card in the config. It really is a _global_ option. > > So if you have two MMC cards (which is theoretically possible, if you have > enough GPIO lines), you'd need _one_ global gpiomask that holds the bits of > both card's GPIO lines. > > In the end, I think we first need to figure out what the gpiomask in diag > really > does. Ok, I looked at the diag code and I think this simply isn't going to work. That gpiomask is a global mask that everybody can override. In the end, I think diag needs a rewrite on 2.6 to use led-triggers and stuff, properly. In any case, the gpiomask does not belong into the mmc_over_gpio config file. It belongs into a diag config file. We can not correctly set it from within the mmc_over_gpio config. For example, what if another application or driver also wants to set the mask? So it will end up overriding it (or we override its settings). Read/set/write of the proc file is also not an option, as that's racy and doesn't work very well in a shell script. So this gpiomask really belongs into a seperate diag-specific config file. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] anyone working to add 2.6.24 support for brcm47xx?
On Saturday 22 March 2008 21:00:56 Alfred E. Heggestad wrote: > Robert P. J. Day wrote: > > i've started digging into how to add 2.6.24 kernel support for > > brcm47xx, which includes updating the Config.in files, the kernel > > .config file, the patches and so on. > > > > is anyone else working on that? some of it's fairly > > straightforward, and i've rebased a lot of the brcm47xx-specific > > patches, but there are a few i'm not sure what to do with, so if > > anyone is the official MIPS support person here, i'd love to chat. > > thanks. > > > > hi, I am not working on upgrading to 2.6.24 but I would certainly > like to try it on my Asus WL500GP. I am currently running 2.6.23.1. > > > I would also like to try a tickless kernel, if that feature > is ported to mips? My plan was to wait for 2.6.25 and update to that then. Updating to 2.6.24 should be possible. But some of the bcm47xx stuff got merged upstream and the upstream stuff is outdated. So one would still need to take care to properly patch that and keep the bcm47xx code at what we currently use in .23. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] anyone working to add 2.6.24 support for brcm47xx?
On Saturday 22 March 2008 21:22:41 Robert P. J. Day wrote: > On Sat, 22 Mar 2008, Michael Buesch wrote: > > > On Saturday 22 March 2008 21:00:56 Alfred E. Heggestad wrote: > > > Robert P. J. Day wrote: > > > > i've started digging into how to add 2.6.24 kernel support for > > > > brcm47xx, which includes updating the Config.in files, the kernel > > > > .config file, the patches and so on. > > > > > > > > is anyone else working on that? some of it's fairly > > > > straightforward, and i've rebased a lot of the brcm47xx-specific > > > > patches, but there are a few i'm not sure what to do with, so if > > > > anyone is the official MIPS support person here, i'd love to chat. > > > > thanks. > > > > > > > > > > hi, I am not working on upgrading to 2.6.24 but I would certainly > > > like to try it on my Asus WL500GP. I am currently running 2.6.23.1. > > > > > > > > > I would also like to try a tickless kernel, if that feature > > > is ported to mips? > > > > My plan was to wait for 2.6.25 and update to that then. Updating to > > 2.6.24 should be possible. But some of the bcm47xx stuff got merged > > upstream and the upstream stuff is outdated. So one would still need > > to take care to properly patch that and keep the bcm47xx code at > > what we currently use in .23. > > if you want to try 2.6.25, you can at least start rebasing patches > against the current git pull, which is 2.6.25-rc6. at this point, not > much is going to change between this rc and the final 2.6.25. Yeah. I will start with that as time allows me to. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mmc-over-gpio driver and fon2100
On Thursday 03 April 2008 20:25:57 Oliver Ertl wrote: > I've built trunk revision 10700 with the new mmc-over-gpio driver for the > atheros target (router is a fon2100). Kernel is 2.6.23.16. I successfully got > the new driver working on a WRT54GL. > > After booting the fon2100 I get unknown symbols: > > ath_rate_minstrel: look around rate set to 10% > ath_rate_minstrel: EWMA rolloff level set to 75% > ath_rate_minstrel: max segment size in the mrr set to 6000 us > wlan: mac acl policy registered > ath_ahb: trunk > wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps > 36Mbps 48Mbps 54Mbps > wifi0: H/W encryption support: WEP AES AES_CCM TKIP > ath_ahb: wifi0: Atheros 2315 WiSoC: mem=0xb000, irq=3 > spi_gpio: Unknown symbol gpio_free > spi_gpio: Unknown symbol gpio_direction_output > spi_gpio: Unknown symbol gpio_set_value > spi_gpio: Unknown symbol gpio_direction_input > spi_gpio: Unknown symbol gpio_get_value > spi_gpio: Unknown symbol gpio_request > spi-gpio-mmc: MMC-Card "fonera" attached to GPIO pins 1,3,4,7 > > Maybe someone knows how to fix it. Your architecture doesn't seem to implement the GPIO API. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mmc-over-gpio driver and fon2100
On Thursday 03 April 2008 22:25:58 Axel Gembe wrote: > [EMAIL PROTECTED] wrote: > > working on the commit this very moment > > > Yay! :) > I think I'm gonna look into making the GPIO pins configurable in > mmc-over-gpio now... Ehm, this _is_ completely configurable and dynamic via sysfs. See the mmc-over-gpio config file in /etc -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Building the b43 module out of compat-wireless in mac80211 package
On Sunday 20 April 2008 23:24:00 Hauke Mehrtens wrote: > With this patch the b43 module will be build in the mac80211 package. > The b43 package should be removed than. NACK, this will cause major problems when we update the SSB API, as SSB is part of the kernel. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] usb ehci driver for ssb
On Monday 02 June 2008 23:30:52 Steve Brown wrote: > This patch adds a ssb ehci driver as well as support for ssb > multifunction cores. > > It is needed to use the ehci function in the BCM5354's USB2 core. > > See https://dev.openwrt.org/ticket/3365 and > http://forum.openwrt.org/viewtopic.php?id=15106&p=2 for reports of > independent testing. > > Signed-off-by: Steve Brown <[EMAIL PROTECTED]> Your changes to the ssb scanning look like a horrible hack. What are you trying to do? The addition of the "nr_cores" variable looks bogus, too. I think this should all be handled in the driver, like b43 does it, too. b43 is also a multifunction device. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] usb ehci driver for ssb
On Tuesday 03 June 2008 17:56:10 Felipe Maya wrote: > The kernel 2.6.26 has these changes and seem to work well No it doesn't have these changes. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] usb ehci driver for ssb
On Wednesday 04 June 2008 23:56:36 Steve Brown wrote: > Here is another cut at an ssb ehci driver. > > Hope this is closer. > > Steve > > Ok, looks a lot better. Thanks. But I'm still not sure on the "companion" pointer. I think it should probably live in struct ssb_ehci_device. My intention to do this, actually, always was to leave the SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_USB20_HOST, SSB_ANY_REV), entry in the ohci table. Then add code to the init and exit paths of the ohci module that would simply call into the ehci driver. So the ehci driver would not register a ssb device, but would rather be a library module for the main ohci module. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] usb ehci driver for ssb
On Friday 06 June 2008 06:37:49 Steve Brown wrote: > I will switch things around so the ohci driver calls the ehci driver. I > will remove the ssb register/unregister calls in ehci-hcd and add calls > from to attach, detach, suspend and resume from ohci to ehci. > > It's probably safe to assume that the ohci driver will be always be > built and to have it call the ehci driver where both the ehci driver is > built and there is a USB20 core. I can also remove any code in the ehci > driver that deals with core housekeeping. I like that. Yeah great. Thanks a lot. Don't forget to also submit it upstream. :) -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add ehci host support for BCM5354 USB20 core
On Sunday 08 June 2008 02:08:14 Steve Brown wrote:
> This adds support for the ehci host function of the USB20 ssb core in
> the Broadcom BCM5354 to the ehci-hcd driver. That core implements both
> ehci and ohci. The driver is implemented as a library or extension to
> the ohci-ssb support in the ohci-hcd driver and is not standalone. It
> must load before the ohci-hcd driver.
>
> Signed-off-by: Steve Brown <[EMAIL PROTECTED]>
>
> ---
>
>
>
++ if (dev->id.coreid == SSB_DEV_USB20_HOST) {
++ ohcidev->companion = &dev->bus->devices[dev->bus->nr_devices];
++ dev->bus->nr_devices++;
++ if (dev->bus->nr_devices > ARRAY_SIZE(dev->bus->devices)) {
++ printk(KERN_ERR
++ "More than %d devs, could not create ohci dev
(%d)\n",
++ SSB_MAX_NR_CORES, dev->bus->nr_devices);
++ return err;
++ }
++ memcpy(ohcidev->companion, dev, sizeof(struct ssb_device));
++ err = ssb_ehci_attach(ohcidev->companion);
++ }
I still really don't like this.
Why do you copy the device? This is going to cause all kinds of weird problems
with refcounts and so on.
You should simply share one device between the modules.
Simply get rid of all this "companion" logic and share the pointer.
The rest looks OK (except for indentation errors)
--
Greetings Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add ehci host support for BCM5354 USB20 core
On Monday 09 June 2008 01:29:58 Steve Brown wrote: > Hopefully, this is the last version. > The issue was keeping track of the ehci hcd pointer. It's now in ohcidev. Great. I like it very much, except for the remaining coding style errors. :) Thanks a lot for this. Please make sure to run this through checkpatch and check for codingstyle and then submit it upstream later. You can send this to the USB maintainer, maybe. Please CC me. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add ehci host support for BCM5354 USB20 core
On Monday 09 June 2008 13:48:35 Steve Brown wrote: > This adds support to ehci-hcd for the ehci host function of the USB20 ssb > core in the Broadcom BCM5354. That core implements both ehci and ohci. The > support is implemented as a library or extension to the ohci-ssb support in > the ohci-hcd driver and is not standalone. The ehci-hcd driver must load > before the ohci-hcd driver. > > Signed-off-by: Steve Brown <[EMAIL PROTECTED]> > Cc: Michael Buesch <[EMAIL PROTECTED]> Do you have commit access to SVN? If not, I'll commit it for you. (I assume you tested this patch and it works correctly). -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
On Sunday 29 June 2008 15:12:47 Steve Brown wrote:
> What should I do next?
Can you try this patch?
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2008-06-26
18:05:10.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c2008-06-29
18:56:07.0 +0200
@@ -3730,9 +3730,10 @@ static int b43_phy_versioning(struct b43
tmp = 0x5205017F;
} else {
b43_write16(dev, B43_MMIO_RADIO_CONTROL, B43_RADIOCTL_ID);
- tmp = b43_read16(dev, B43_MMIO_RADIO_DATA_LOW);
+ tmp = b43_read16(dev, B43_MMIO_RADIO_DATA_HIGH);
+ tmp <<= 16;
b43_write16(dev, B43_MMIO_RADIO_CONTROL, B43_RADIOCTL_ID);
- tmp |= (u32)b43_read16(dev, B43_MMIO_RADIO_DATA_HIGH) << 16;
+ tmp |= b43_read16(dev, B43_MMIO_RADIO_DATA_LOW);
}
radio_manuf = (tmp & 0x0FFF);
radio_ver = (tmp & 0x0000) >> 12;
--
Greetings Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
On Sunday 29 June 2008 21:04:28 Steve Brown wrote:
> Michael Buesch wrote:
> > On Sunday 29 June 2008 15:12:47 Steve Brown wrote:
> >
> >> What should I do next?
> >>
> >
> > Can you try this patch?
> >
> > Index: wireless-testing/drivers/net/wireless/b43/main.c
> > ===
> > --- wireless-testing.orig/drivers/net/wireless/b43/main.c 2008-06-26
> > 18:05:10.0 +0200
> > +++ wireless-testing/drivers/net/wireless/b43/main.c2008-06-29
> > 18:56:07.0 +0200
> > @@ -3730,9 +3730,10 @@ static int b43_phy_versioning(struct b43
> > tmp = 0x5205017F;
> > } else {
> > b43_write16(dev, B43_MMIO_RADIO_CONTROL, B43_RADIOCTL_ID);
> > - tmp = b43_read16(dev, B43_MMIO_RADIO_DATA_LOW);
> > + tmp = b43_read16(dev, B43_MMIO_RADIO_DATA_HIGH);
> > + tmp <<= 16;
> > b43_write16(dev, B43_MMIO_RADIO_CONTROL, B43_RADIOCTL_ID);
> > - tmp |= (u32)b43_read16(dev, B43_MMIO_RADIO_DATA_HIGH) << 16;
> > + tmp |= b43_read16(dev, B43_MMIO_RADIO_DATA_LOW);
> > }
> > radio_manuf = (tmp & 0x0FFF);
> > radio_ver = (tmp & 0x0000) >> 12;
> >
> >
> >
> I had tried the same thing earlier this morning thinking that as the
> working code had the order reversed, that might be the problem. But, to
> be thorough, I applied your patch as well. Same result.
>
> The only difference I can see is:
> Bus error version:
> b43-phy0: Broadcom 4318 WLAN found
> drivers/ssb/pci.c:604 mmio:0xc000 offset:0x3e0
> drivers/ssb/pci.c:604 mmio:0xc000 offset:0x3f8
> Data bus error, epc == 8011950c, ra == 80161164
>
> Working version:
> b43-phy0: Broadcom 4318 WLAN found
> drivers/ssb/pci.c:535 mmio:0xc0074000 offset:0x3e0
> drivers/ssb/pci.c:535 mmio:0xc0074000 offset:0x3f8
> drivers/ssb/pci.c:535 mmio:0xc0074000 offset:0x3fa
> drivers/ssb/pci.c:535 mmio:0xc0074000 offset:0x3fe
> drivers/ssb/pci.c:535 mmio:0xc0074000 offset:0x3fe
>
> The thing that confounds me is that 0x3e0 returns good data, 0x3fa
> returns good data, but 0x3f8 bus errors. If my understanding is correct
> that a bus error is essentially an access timeout, I sure can't explain
> a hole in the middle of the register space?
>
> To be sure it was really a hole and the entire register space didn't
> just disappear after the 0x3fa read, I repeated the 0x3fa read.
> Same problem:
> b43-phy0: Broadcom 4318 WLAN found
> drivers/ssb/pci.c:604 mmio:0xc000 offset:0x3e0
> drivers/ssb/pci.c:604 mmio:0xc000 offset:0x3fa
> drivers/ssb/pci.c:604 mmio:0xc000 offset:0x3fa -- DUPLICATE --
> drivers/ssb/pci.c:604 mmio:0xc000 offset:0x3f8
> Data bus error, epc == 8011950c, ra == 80161164
I'm sorry, I cannot tell you what causes this. But I guess, however,
it is some change in the ssb setup code that broke this.
--
Greetings Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
On Tuesday 01 July 2008 21:50:43 Steve Brown wrote: > It looks like (almost) every other phy register doesn't respond. I put > in a large (200us) delay between accesses with no change in behaviour. > If it is timing, it must be on the pci bus side of the core. Ah this is a minipci card? Can you try to play with the PCI bus timings that are initialised in the PCI-core driver of SSB? See the function that initialises the PCI-core in hostmode. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [rfc] Kernel sources download strategy
On Thursday 03 July 2008 11:01:17 Luigi 'Comio' Mantellini wrote: > Hi All, > > > I know that what I say usually is ignored :D But I like to flood this ml > with stupid(?) ideas. > > The actual OpenWRT considers kernels 2.6.X.Y and 2.6.X.(Y+1) as a very > different kernels downloading the full sources for both. I think that > this is not a good approach because this is time and band expensive. > > An idea should be to download the full sources 2.6.X kernels and just > the patches 2.6.X.1, 2.6.X.2, ... 2.6.X.Y to cover the kernels with > version like 2.6.X.Y. The result will be a gain in terms of band and > time utilization. > > I think that to achieve this the download perl and make scripts should > be made more smart than actual versions > > These optimizations should be applied also to gcc and uclibc and any > other package that provides diff between versions. > > Thanks a lot for your comments. -ENOPATCH ? -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
On Friday 04 July 2008 21:39:46 Steve Brown wrote: > Michael Buesch wrote: > > On Tuesday 01 July 2008 21:50:43 Steve Brown wrote: > > > >> It looks like (almost) every other phy register doesn't respond. I put > >> in a large (200us) delay between accesses with no change in behaviour. > >> If it is timing, it must be on the pci bus side of the core. > >> > > > > Ah this is a minipci card? > > Can you try to play with the PCI bus timings that are initialised in > > the PCI-core driver of SSB? See the function that initialises the > > PCI-core in hostmode. > > > > > The problem is actually in b44. The ssb_pcicore_dev_irqvecs_enable call > in b44_chip_enable at b44.c:1281 is the cause of the problem. It gets > called unconditionally, even if the b44 is not on the pci. With it > commented out, b43 loads, loads firmware and returns scan results. > > It crept in sometime after 2.6.23.1. I'm not familiar with b44 and can't > offer a fix. > > I still don't understand how this caused the bus errors. Anybody got an > explanation? So do you have a PCI bus on the system? Is the wireless connected via minipci? -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ssb-pcicore: Fix IRQ-vector init on embedded devices
On embedded devices we must not route the interrupts through
the PCI core, if our host-bus is not PCI.
Reported-by: Steve Brown <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
---
John, If still possible, please queue for 2.6.26.
Index: wireless-testing/drivers/ssb/driver_pcicore.c
===
--- wireless-testing.orig/drivers/ssb/driver_pcicore.c 2008-06-10
13:58:23.0 +0200
+++ wireless-testing/drivers/ssb/driver_pcicore.c 2008-07-04
23:16:02.0 +0200
@@ -537,6 +537,13 @@ int ssb_pcicore_dev_irqvecs_enable(struc
int err = 0;
u32 tmp;
+ if (dev->bus->bustype != SSB_BUSTYPE_PCI) {
+ /* This SSB device is not on a PCI host-bus. So the IRQs are
+* not routed through the PCI core.
+* So we must not enable routing through the PCI core. */
+ goto out;
+ }
+
if (!pdev)
goto out;
bus = pdev->bus;
--
Greetings Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
On Saturday 05 July 2008 11:25:23 Tomasz Chmielewski wrote: > Stefan Monnier schrieb: > > (...) > > >> The b43 driver now loads, loads firmware and returns scan results. > > > > With the above patch (and a freshly updated svn checkout of Kamikaze), > > my WL700gE indeed loads the driver, it seems to load the firmware as > > well, but something goes wrong afterwards and I don't get any network > > interface. The corresponding dmesg output is: > > > >b43-phy0: Broadcom 4318 WLAN found > >b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7 > >b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 8 > >b43-phy0 debug: DebugFS (CONFIG_DEBUG_FS) not enabled in kernel config > >phy0: Selected rate control algorithm 'pid' > >phy0: Failed to initialize wep Configure mac80211 crypto correctly. compile all needed crypto modules. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2.6 kernel and b43 driver
On Saturday 05 July 2008 20:31:34 Tomasz Chmielewski wrote: > Tomasz Chmielewski schrieb: > > Tomasz Chmielewski schrieb: > >> Tomasz Chmielewski schrieb: > >>> Steve Brown schrieb: > >>> > >>> (...) > >>> > >>> And I don't think firmware is loaded - I have exactly the same > >>> output when I don't even have /lib/firmware/b43 directory. > >>> > >>> > >>> > >> I cannot reproduce your results. For me, the patch works fine. > > Could you post your kernel .config? > > > I have posted my kernel config (which is pretty big) and some comments > to the thread at http://forum.openwrt.org/viewtopic.php?id=15443&p=1. > >>> Indeed, it works here as well, thanks a lot! > >> Ouch: > > > > (...) > > > >> Code: a021 8ec3000c 8fa40050 <9074> 9082038a 0202102b > >> 1446 3c04c010 3c028002 > >> Kernel panic - not syncing: Fatal exception in interrupt > > > > This behaves... interesting. > > > > Paste it after booting, and it will print two warnings. > > > > I can't reproduce the panic any more though. > > Ah, it panics as soon as I try to ping it from the other host. > > You should probably report this to [EMAIL PROTECTED] -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Add SPI over GPIO driver
This adds a driver that lets you drive an SPI bus over
generic GPIO pins.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
---
This driver is used in OpenWrt since quite some time, so please
consider for inclusion in mainline.
Index: linux-next/include/linux/spi/spi_gpio.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/include/linux/spi/spi_gpio.h 2008-07-14 20:52:48.0
+0200
@@ -0,0 +1,53 @@
+/*
+ * spi_gpio interface to platform code
+ *
+ * Copyright (c) 2008 Piotr Skamruk
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef _LINUX_SPI_SPI_GPIO
+#define _LINUX_SPI_SPI_GPIO
+
+#include
+#include
+
+
+/** struct spi_gpio_platform_data - Data definitions for a SPI-GPIO device.
+ * This structure holds information about a GPIO-based SPI device.
+ *
+ * @pin_clk: The GPIO pin number of the CLOCK pin.
+ *
+ * @pin_miso: The GPIO pin number of the MISO pin.
+ *
+ * @pin_mosi: The GPIO pin number of the MOSI pin.
+ *
+ * @pin_cs: The GPIO pin number of the CHIPSELECT pin.
+ *
+ * @cs_activelow: If true, the chip is selected when the CS line is low.
+ *
+ * @no_spi_delay: If true, no delay is done in the lowlevel bitbanging.
+ *Note that doing no delay is not standards compliant,
+ *but it might be needed to speed up transfers on some
+ *slow embedded machines.
+ *
+ * @boardinfo_setup: This callback is called after the
+ * SPI master device was registered, but before the
+ * device is registered.
+ * @boardinfo_setup_data: Data argument passed to boardinfo_setup().
+ */
+struct spi_gpio_platform_data {
+ unsigned int pin_clk;
+ unsigned int pin_miso;
+ unsigned int pin_mosi;
+ unsigned int pin_cs;
+ bool cs_activelow;
+ bool no_spi_delay;
+ int (*boardinfo_setup)(struct spi_board_info *bi,
+ struct spi_master *master,
+ void *data);
+ void *boardinfo_setup_data;
+};
+
+#endif /* _LINUX_SPI_SPI_GPIO */
Index: linux-next/drivers/spi/spi_gpio.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/drivers/spi/spi_gpio.c 2008-07-14 21:03:40.0 +0200
@@ -0,0 +1,242 @@
+/*
+ * Bitbanging SPI bus driver using GPIO API
+ *
+ * Copyright (c) 2008 Piotr Skamruk
+ * Copyright (c) 2008 Michael Buesch
+ *
+ * based on spi_s3c2410_gpio.c
+ * Copyright (c) 2006 Ben Dooks
+ * Copyright (c) 2006 Simtec Electronics
+ * and on i2c-gpio.c
+ * Copyright (C) 2007 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+struct spi_gpio {
+ struct spi_bitbang bitbang;
+ struct spi_gpio_platform_data *info;
+ struct platform_device *pdev;
+ struct spi_board_info bi;
+};
+
+
+static inline struct spi_gpio *spidev_to_sg(struct spi_device *dev)
+{
+ return dev->controller_data;
+}
+
+static inline void setsck(struct spi_device *dev, int val)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ gpio_set_value(sp->info->pin_clk, val ? 1 : 0);
+}
+
+static inline void setmosi(struct spi_device *dev, int val)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ gpio_set_value(sp->info->pin_mosi, val ? 1 : 0);
+}
+
+static inline u32 getmiso(struct spi_device *dev)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ return gpio_get_value(sp->info->pin_miso) ? 1 : 0;
+}
+
+static inline void do_spidelay(struct spi_device *dev, unsigned nsecs)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+
+ if (!sp->info->no_spi_delay)
+ ndelay(nsecs);
+}
+
+#define spidelay(nsecs) do { \
+ /* Steal the spi_device pointer from our caller.\
+* The bitbang-API should probably get fixed here... */ \
+ do_spidelay(spi, nsecs);\
+ } while (0)
+
+#define EXPAND_BITBANG_TXRX
+#include
+
+static u32 spi_gpio_txrx_mode0(struct spi_device *spi,
+ unsigned nsecs, u32 word, u8 bits)
+{
+ return bitbang_txrx_be_cpha0(spi, nsecs, 0, word, bits);
+}
+
+static u32 spi_gpio_txrx_mode1(struct spi_device *spi,
+ unsigned nsecs, u32 word, u8 bits)
+{
+ return bitbang_txrx_be_cpha1(spi, nsecs, 0, word, bits);
+}
+
+static u32 spi_gpio_txrx_mode2(struct spi_device *spi,
+
[OpenWrt-Devel] [PATCH] Add dynamic MMC-over-SPI-GPIO driver
This driver provides a sysfs interface to dynamically create
and destroy GPIO-based MMC/SD card interfaces.
So an MMC or SD card can be connected to generic GPIO pins
and be configured dynamically from userspace.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
---
This driver is used in OpenWrt since quite some time, so please
consider for inclusion in mainline.
See the attached OpenWrt initscript for an example on how to use
the sysfs interface. Documentation should also be added. I'll submit
a patch for that, later.
Index: linux-next/drivers/mmc/host/mmc_over_spigpio.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/drivers/mmc/host/mmc_over_spigpio.c 2008-07-14
21:04:51.0 +0200
@@ -0,0 +1,339 @@
+/*
+ * Driver for driving an MMC card over a bitbanging GPIO SPI bus.
+ *
+ * Copyright 2008 Michael Buesch <[EMAIL PROTECTED]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#include
+#include
+#include
+#include
+
+
+/* This is the maximum speed in Hz */
+#define GPIOMMC_MAXSPEED 500 /* Hz */
+
+
+#define DRIVER_NAME"spi-gpio-mmc"
+#define PFXDRIVER_NAME ": "
+
+
+#define GPIOMMC_MAX_NAMELEN15
+#define GPIOMMC_MAX_NAMELEN_STR__stringify(GPIOMMC_MAX_NAMELEN)
+
+struct gpiommc_pins {
+ unsigned int gpio_di; /* Card DI pin */
+ unsigned int gpio_do; /* Card DO pin */
+ unsigned int gpio_clk; /* Card CLK pin */
+ unsigned int gpio_cs; /* Card CS pin */
+};
+
+struct gpiommc_device {
+ char name[GPIOMMC_MAX_NAMELEN + 1];
+ struct platform_device *pdev;
+ struct platform_device *spi_pdev;
+ struct gpiommc_pins pins;
+ u8 mode; /* SPI_MODE_X */
+ struct spi_board_info boardinfo;
+
+ struct list_head list;
+};
+
+
+static LIST_HEAD(gpiommc_devices_list);
+static DEFINE_MUTEX(gpiommc_mutex);
+
+
+MODULE_DESCRIPTION("SPI-GPIO based MMC driver");
+MODULE_AUTHOR("Michael Buesch");
+MODULE_LICENSE("GPL");
+
+
+static int gpiommc_boardinfo_setup(struct spi_board_info *bi,
+ struct spi_master *master,
+ void *data)
+{
+ struct gpiommc_device *d = data;
+
+ /* Bind the SPI master to the MMC-SPI host driver. */
+ strlcpy(bi->modalias, "mmc_spi", sizeof(bi->modalias));
+
+ bi->max_speed_hz = GPIOMMC_MAXSPEED;
+ bi->bus_num = master->bus_num;
+ bi->mode = d->mode;
+
+ return 0;
+}
+
+static int gpiommc_probe(struct platform_device *pdev)
+{
+ static int instance;
+ struct gpiommc_device *d = platform_get_drvdata(pdev);
+ struct spi_gpio_platform_data pdata;
+ int err = -ENOMEM;
+
+ d->spi_pdev = platform_device_alloc("spi-gpio", instance++);
+ if (!d->spi_pdev)
+ goto out;
+
+ memset(&pdata, 0, sizeof(pdata));
+ pdata.pin_clk = d->pins.gpio_clk;
+ pdata.pin_miso = d->pins.gpio_do;
+ pdata.pin_mosi = d->pins.gpio_di;
+ pdata.pin_cs = d->pins.gpio_cs;
+ pdata.cs_activelow = 1;
+ pdata.no_spi_delay = 1;
+ pdata.boardinfo_setup = gpiommc_boardinfo_setup;
+ pdata.boardinfo_setup_data = d;
+
+ err = platform_device_add_data(d->spi_pdev, &pdata, sizeof(pdata));
+ if (err)
+ goto err_free_pdev;
+ err = platform_device_register(d->spi_pdev);
+ if (err)
+ goto err_free_pdata;
+
+ printk(KERN_INFO PFX "MMC-Card \"%s\" "
+ "attached to GPIO pins %u,%u,%u,%u\n",
+ d->name, d->pins.gpio_di, d->pins.gpio_do,
+ d->pins.gpio_clk, d->pins.gpio_cs);
+out:
+ return err;
+
+err_free_pdata:
+ kfree(d->spi_pdev->dev.platform_data);
+ d->spi_pdev->dev.platform_data = NULL;
+err_free_pdev:
+ platform_device_put(d->spi_pdev);
+ return err;
+}
+
+static int gpiommc_remove(struct platform_device *pdev)
+{
+ struct gpiommc_device *d = platform_get_drvdata(pdev);
+
+ platform_device_unregister(d->spi_pdev);
+ printk(KERN_INFO PFX "MMC-Card \"%s\" removed\n", d->name);
+
+ return 0;
+}
+
+static void gpiommc_free(struct gpiommc_device *d)
+{
+ kfree(d);
+}
+
+static struct gpiommc_device *gpiommc_alloc(struct platform_device *pdev,
+ const char *name,
+ const struct gpiommc_pins *pins,
+ u8 mode)
+{
+ struct gpiommc_device *d;
+
+ d = kmalloc(sizeof(*d), GFP_KERNEL);
+ if (!d)
+ return NULL;
+
+ strcpy(d->name, name);
+ memcpy(&a
Re: [OpenWrt-Devel] [PATCH] Add SPI over GPIO driver
On Monday 14 July 2008 22:43:45 Andrew Morton wrote:
> On Mon, 14 Jul 2008 21:09:12 +0200
> Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > +static inline void do_spidelay(struct spi_device *dev, unsigned nsecs)
> > +{
> > + struct spi_gpio *sp = spidev_to_sg(dev);
> > +
> > + if (!sp->info->no_spi_delay)
> > + ndelay(nsecs);
> > +}
> > +
> > +#define spidelay(nsecs) do { \
> > + /* Steal the spi_device pointer from our caller.\
> > +* The bitbang-API should probably get fixed here... */ \
> > + do_spidelay(spi, nsecs);\
> > + } while (0)
>
> A macro which requires that its caller have a particular local variable
> is a bit nasty. Could we plan to add the spi_device* to spidelay()
> please?
Yeah right. I was planning to fix this later on _after_ this was merged.
This makes the merge easier with less patch cross-dependencies.
--
Greetings Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add dynamic MMC-over-SPI-GPIO driver
On Monday 14 July 2008 22:54:41 Andrew Morton wrote:
> > +static int gpiommc_probe(struct platform_device *pdev)
> > +{
> > + static int instance;
> > + struct gpiommc_device *d = platform_get_drvdata(pdev);
> > + struct spi_gpio_platform_data pdata;
> > + int err = -ENOMEM;
> > +
> > + d->spi_pdev = platform_device_alloc("spi-gpio", instance++);
> > + if (!d->spi_pdev)
> > + goto out;
>
> I guess that incrementing `instance' even if the allocation failed is
> somewhat wrong.
Well, I guess it doesn't matter much. The number is pretty random anyway.
> > +static struct gpiommc_device *gpiommc_alloc(struct platform_device *pdev,
> > + const char *name,
> > + const struct gpiommc_pins *pins,
> > + u8 mode)
> > +{
> > + struct gpiommc_device *d;
> > +
> > + d = kmalloc(sizeof(*d), GFP_KERNEL);
> > + if (!d)
> > + return NULL;
> > +
> > + strcpy(d->name, name);
>
> No check for overruns?
The caller checks the length, but it is a good idea to double-check here.
Good catch.
> > + memcpy(&d->pins, pins, sizeof(d->pins));
>
> If this had used the typesafe
>
> d->pins = *pins;
>
> I wouldn't have needed to run all around the place working out if
> overflow/underflow checks were needed here.
Yeah well, can use this.
> > +static ssize_t gpiommc_add_store(struct device_driver *drv,
> > +const char *buf, size_t count)
> > +{
> > + int res, err;
> > + char name[GPIOMMC_MAX_NAMELEN + 1];
> > + struct gpiommc_pins pins;
> > + unsigned int mode;
> > +
> > + res = sscanf(buf, "%" GPIOMMC_MAX_NAMELEN_STR "s %u,%u,%u,%u %u",
> > +name, &pins.gpio_di, &pins.gpio_do,
> > +&pins.gpio_clk, &pins.gpio_cs, &mode);
>
> What's going on here? So new kernel/userspace ABI.
The whole point of the module is to create a new userspace interface for
creating the device. The module does just glue several modules together
and create an actual device.
> Not documented in
> changelog, not documented in code comments, not documented in
> Documentation/ABI. This forces reviewers to reverse-engineer the
> interface design from the implementation and then attempt to review
> that design. Reviewers not happy!
Yeah well, as I said, I will do docs later. I didn't have any time
to write documentation, yet.
by. ;)
> > +static ssize_t gpiommc_remove_show(struct device_driver *drv,
> > + char *buf)
> > +{
> > + return snprintf(buf, PAGE_SIZE, "write device-name to remove the
> > device\n");
> > +}
>
> Now that is one weird way in which to document the interface! What a
> waste of kernel text :(
Yeah, well. Better than nothing ;)
As I already said in the original patch announcement. This is by no way the
final version of the patch. Docs will be moved to Documentation/
--
Greetings Michael.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add dynamic MMC-over-SPI-GPIO driver
On Tuesday 15 July 2008 07:06:49 Ben Nizette wrote: > > On Mon, 2008-07-14 at 21:09 +0200, Michael Buesch wrote: > > This driver provides a sysfs interface to dynamically create > > and destroy GPIO-based MMC/SD card interfaces. > > So an MMC or SD card can be connected to generic GPIO pins > > and be configured dynamically from userspace. > > Can you use mmc-spi attached to spi-gpio and be done with it? This is _exactly_ what this module does. It combines mmc-spi and spi-gpio and creates an actual device for them. > Sure you > won't have the dynamic alloc capability but you won't be reinventing the > wheel either. This does not reinvent anything. It just wires up the two modules. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add SPI over GPIO driver
On Tuesday 15 July 2008 07:30:51 Ben Nizette wrote: > Looks good overall. I'm not sure that it need pretend to be > hotpluggable though Because the hardware _is_ hotpluggable. > (i.e. the board info can be hardwired so there's no > need for the board setup callback). I'm not sure why we should limit ourselves so much by compiling dynamic and completely individual information, like the bus wireing into the kernel. This _has_ to be dynamic, as the wireing is _completely_ random and different for every machine. This is selfmade hardware. ;) > What problem are you solving (or whole in board support are you > plugging) in this dynamic plugging of MMCs? This is to support running MMCs/SDs on GPIO pins. Which board or card provides the GPIO pins doesn't matter. It doesn't matter, as it's completely abstracted. You can even run 10 or more of the cards at the same time, if you have enough GPIO pins. Of course, this is mostly useful for embedded systems only. But it is not bound to any specific type of hardware. The hardware just has to implement generic GPIO for its GPIO pins. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add dynamic MMC-over-SPI-GPIO driver
On Tuesday 15 July 2008 02:07:57 RHS Linux User wrote: > > Hi All, > >I wonder if this MMC driver can be extended to support 2 MMC devices? It does support an infinite amount of devices. See the initscript for adding another one. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add dynamic MMC-over-SPI-GPIO driver
On Monday 14 July 2008 21:09:18 Michael Buesch wrote: > This driver provides a sysfs interface to dynamically create > and destroy GPIO-based MMC/SD card interfaces. > So an MMC or SD card can be connected to generic GPIO pins > and be configured dynamically from userspace. Ok, I had requests in private to also allow registering the platform device from outside of the module (and use platform data). This is used for certain embedded hardware from the arch code to statically create a GPIO-based MMC device. I'll add that and resend along with the proposed fixes. Thanks for the review! :) -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] Add SPI over GPIO driver
This adds a driver that lets you drive an SPI bus over
generic GPIO pins.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
---
This driver is used in OpenWrt since quite some time, so please
consider for inclusion in mainline.
Index: linux-next/include/linux/spi/spi_gpio.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/include/linux/spi/spi_gpio.h 2008-07-15 20:44:30.0
+0200
@@ -0,0 +1,67 @@
+/*
+ * spi_gpio interface to platform code
+ *
+ * Copyright (c) 2008 Piotr Skamruk
+ * Copyright (c) 2008 Michael Buesch
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef _LINUX_SPI_SPI_GPIO
+#define _LINUX_SPI_SPI_GPIO
+
+#include
+#include
+
+
+/** struct spi_gpio_platform_data - Data definitions for a SPI-GPIO device.
+ * This structure holds information about a GPIO-based SPI device.
+ *
+ * @pin_clk: The GPIO pin number of the CLOCK pin.
+ *
+ * @pin_miso: The GPIO pin number of the MISO pin.
+ *
+ * @pin_mosi: The GPIO pin number of the MOSI pin.
+ *
+ * @pin_cs: The GPIO pin number of the CHIPSELECT pin.
+ *
+ * @cs_activelow: If true, the chip is selected when the CS line is low.
+ *
+ * @no_spi_delay: If true, no delay is done in the lowlevel bitbanging.
+ *Note that doing no delay is not standards compliant,
+ *but it might be needed to speed up transfers on some
+ *slow embedded machines.
+ *
+ * @boardinfo_setup: This callback is called after the
+ * SPI master device was registered, but before the
+ * device is registered.
+ * @boardinfo_setup_data: Data argument passed to boardinfo_setup().
+ */
+struct spi_gpio_platform_data {
+ unsigned int pin_clk;
+ unsigned int pin_miso;
+ unsigned int pin_mosi;
+ unsigned int pin_cs;
+ bool cs_activelow;
+ bool no_spi_delay;
+ int (*boardinfo_setup)(struct spi_board_info *bi,
+ struct spi_master *master,
+ void *data);
+ void *boardinfo_setup_data;
+};
+
+/** SPI_GPIO_PLATDEV_NAME - The platform device name string.
+ * The name string that has to be used for platform_device_alloc
+ * when allocating a spi-gpio device.
+ */
+#define SPI_GPIO_PLATDEV_NAME "spi-gpio"
+
+/** spi_gpio_next_id - Get another platform device ID number.
+ * This returns the next platform device ID number that has to be used
+ * for platform_device_alloc. The ID is opaque and should not be used for
+ * anything else.
+ */
+int spi_gpio_next_id(void);
+
+#endif /* _LINUX_SPI_SPI_GPIO */
Index: linux-next/drivers/spi/spi_gpio.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/drivers/spi/spi_gpio.c 2008-07-15 20:41:47.0 +0200
@@ -0,0 +1,251 @@
+/*
+ * Bitbanging SPI bus driver using GPIO API
+ *
+ * Copyright (c) 2008 Piotr Skamruk
+ * Copyright (c) 2008 Michael Buesch
+ *
+ * based on spi_s3c2410_gpio.c
+ * Copyright (c) 2006 Ben Dooks
+ * Copyright (c) 2006 Simtec Electronics
+ * and on i2c-gpio.c
+ * Copyright (C) 2007 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+struct spi_gpio {
+ struct spi_bitbang bitbang;
+ struct spi_gpio_platform_data *info;
+ struct platform_device *pdev;
+ struct spi_board_info bi;
+};
+
+
+static inline struct spi_gpio *spidev_to_sg(struct spi_device *dev)
+{
+ return dev->controller_data;
+}
+
+static inline void setsck(struct spi_device *dev, int val)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ gpio_set_value(sp->info->pin_clk, val ? 1 : 0);
+}
+
+static inline void setmosi(struct spi_device *dev, int val)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ gpio_set_value(sp->info->pin_mosi, val ? 1 : 0);
+}
+
+static inline u32 getmiso(struct spi_device *dev)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ return gpio_get_value(sp->info->pin_miso) ? 1 : 0;
+}
+
+static inline void do_spidelay(struct spi_device *dev, unsigned nsecs)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+
+ if (!sp->info->no_spi_delay)
+ ndelay(nsecs);
+}
+
+#define spidelay(nsecs) do { \
+ /* Steal the spi_device pointer from our caller.\
+* The bitbang-API should probably get fixed here... */ \
+ do_spidelay(spi, nsecs);
[OpenWrt-Devel] [PATCH v2] Add GPIO-based MMC/SD driver
This driver hooks up the mmc_spi and spi_gpio modules so that
MMC/SD cards can be used on a GPIO based bus by bitbanging
the SPI protocol in software.
This driver provides a sysfs interface to dynamically create
and destroy GPIO-based MMC/SD card interfaces. It also provides
a platform device interface API.
See Documentation/gpiommc.txt for details.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
---
This driver is used in OpenWrt since quite some time, so please
consider for inclusion in mainline.
Index: linux-next/drivers/mmc/host/gpiommc.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/drivers/mmc/host/gpiommc.c 2008-07-18 21:54:05.0
+0200
@@ -0,0 +1,328 @@
+/*
+ * Driver an MMC/SD card on a bitbanging GPIO SPI bus.
+ * This module hooks up the mmc_spi and spi_gpio modules and also
+ * provides a sysfs interface.
+ *
+ * Copyright 2008 Michael Buesch <[EMAIL PROTECTED]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+
+#define PFX"gpio-mmc: "
+#define GPIOMMC_MAX_NAMELEN_STR__stringify(GPIOMMC_MAX_NAMELEN)
+
+struct gpiommc_device {
+ struct platform_device *pdev;
+ struct platform_device *spi_pdev;
+ struct spi_board_info boardinfo;
+};
+
+
+MODULE_DESCRIPTION("GPIO based MMC driver");
+MODULE_AUTHOR("Michael Buesch");
+MODULE_LICENSE("GPL");
+
+
+static int gpiommc_boardinfo_setup(struct spi_board_info *bi,
+ struct spi_master *master,
+ void *data)
+{
+ struct gpiommc_device *d = data;
+ struct gpiommc_platform_data *pdata = d->pdev->dev.platform_data;
+
+ /* Bind the SPI master to the MMC-SPI host driver. */
+ strlcpy(bi->modalias, "mmc_spi", sizeof(bi->modalias));
+
+ bi->max_speed_hz = pdata->max_bus_speed;
+ bi->bus_num = master->bus_num;
+ bi->mode = pdata->mode;
+
+ return 0;
+}
+
+static int gpiommc_probe(struct platform_device *pdev)
+{
+ struct gpiommc_platform_data *mmc_pdata = pdev->dev.platform_data;
+ struct spi_gpio_platform_data spi_pdata;
+ struct gpiommc_device *d;
+ int err;
+
+ err = -ENXIO;
+ if (!mmc_pdata)
+ goto error;
+
+ /* Allocate the GPIO-MMC device */
+ err = -ENOMEM;
+ d = kzalloc(sizeof(*d), GFP_KERNEL);
+ if (!d)
+ goto error;
+ d->pdev = pdev;
+
+ /* Create the SPI-GPIO device */
+ d->spi_pdev = platform_device_alloc(SPI_GPIO_PLATDEV_NAME,
+ spi_gpio_next_id());
+ if (!d->spi_pdev)
+ goto err_free_d;
+
+ memset(&spi_pdata, 0, sizeof(spi_pdata));
+ spi_pdata.pin_clk = mmc_pdata->pins.gpio_clk;
+ spi_pdata.pin_miso = mmc_pdata->pins.gpio_do;
+ spi_pdata.pin_mosi = mmc_pdata->pins.gpio_di;
+ spi_pdata.pin_cs = mmc_pdata->pins.gpio_cs;
+ spi_pdata.cs_activelow = mmc_pdata->pins.cs_activelow;
+ spi_pdata.no_spi_delay = mmc_pdata->no_spi_delay;
+ spi_pdata.boardinfo_setup = gpiommc_boardinfo_setup;
+ spi_pdata.boardinfo_setup_data = d;
+
+ err = platform_device_add_data(d->spi_pdev, &spi_pdata,
+ sizeof(spi_pdata));
+ if (err)
+ goto err_free_pdev;
+ err = platform_device_add(d->spi_pdev);
+ if (err)
+ goto err_free_pdata;
+ platform_set_drvdata(pdev, d);
+
+ printk(KERN_INFO PFX "MMC-Card \"%s\" "
+ "attached to GPIO pins di=%u, do=%u, clk=%u, cs=%u\n",
+ mmc_pdata->name, mmc_pdata->pins.gpio_di,
+ mmc_pdata->pins.gpio_do,
+ mmc_pdata->pins.gpio_clk,
+ mmc_pdata->pins.gpio_cs);
+
+ return 0;
+
+err_free_pdata:
+ kfree(d->spi_pdev->dev.platform_data);
+ d->spi_pdev->dev.platform_data = NULL;
+err_free_pdev:
+ platform_device_put(d->spi_pdev);
+err_free_d:
+ kfree(d);
+error:
+ return err;
+}
+
+static int gpiommc_remove(struct platform_device *pdev)
+{
+ struct gpiommc_device *d = platform_get_drvdata(pdev);
+ struct gpiommc_platform_data *pdata = d->pdev->dev.platform_data;
+
+ platform_device_unregister(d->spi_pdev);
+ printk(KERN_INFO PFX "GPIO based MMC-Card \"%s\" removed\n",
pdata->name);
+ platform_device_put(d->spi_pdev);
+
+ return 0;
+}
+
+/* Wrapper for the platform data with context data for the sysfs interface. */
+struct gpiommc_sysfs_platform_data {
+ struct gpiommc_platform_data p; /* Keep as first el
Re: [OpenWrt-Devel] [PATCH v2] Add GPIO-based MMC/SD driver
Thanks for the comments. On Saturday 19 July 2008 00:10:37 Randy Dunlap wrote: > > +To add a new device, simply echo the configuration string to the "add" > > file. > > +The config string is composed out of the following elements: > > + > > +DEVNAME DIpin DOpin CLKpin CSpin SPIMODE MAXBUSSPEED NO_SPI_DELAY > > CSACTIVELOW > > + > > +DEVNAME is a unique name string for the device. > > +DIpin is the SPI DI GPIO pin. > > +DOpin is the SPI DO GPIO pin. > > +CLKpin is the SPI CLOCK GPIO pin. > > +CSpin is the SPI CHIPSELECT GPIO pin. > > +SPIMODE is the hardware mode the device will run at. Can be 0-3. > > +MAXBUSSPEED is the maximum bus speed in Hertz. > > +NO_SPI_DELAY can be 1 or 0. If it is 1, then the lowlevel SPI delay > > +will not be performed. This is not standards compliant, but may be required > > +to gain reasonable speeds on embedded hardware. > > +CSACTIVELOW can be 1 or 0. If it is 1, the chip is considered to be > > selected, if CS > > +is at a logical 0. > > + > > Would this be better done via configfs? sysfs files are supposed to be > single-value files. Well, I really want to avoid over-engineering this thing. I thought about using configfs, but that would require to keep lots of state information across the operations. So one would have to allocate a device with mkdir. Then configure the parameters. And then somehow tell the kernel to register it. State has to be maintained over this time and I'm not sure how that "register" operation would look like. Writing a "1" to a "register" file? So why not write all config parameters to an "add" file and be done with all the stuff. ;) It all depends on how you define "one thing per file", IMO. This "add" file does one thing. It creates a device. We must, of course, pass some configuration parameters, too. -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] Add GPIO-based MMC/SD driver
On Saturday 19 July 2008 00:59:52 Greg KH wrote: > On Sat, Jul 19, 2008 at 12:38:07AM +0200, Michael Buesch wrote: > > Thanks for the comments. > > > > On Saturday 19 July 2008 00:10:37 Randy Dunlap wrote: > > > > +To add a new device, simply echo the configuration string to the "add" > > > > file. > > > > +The config string is composed out of the following elements: > > > > + > > > > +DEVNAME DIpin DOpin CLKpin CSpin SPIMODE MAXBUSSPEED NO_SPI_DELAY > > > > CSACTIVELOW > > > > + > > > > +DEVNAME is a unique name string for the device. > > > > +DIpin is the SPI DI GPIO pin. > > > > +DOpin is the SPI DO GPIO pin. > > > > +CLKpin is the SPI CLOCK GPIO pin. > > > > +CSpin is the SPI CHIPSELECT GPIO pin. > > > > +SPIMODE is the hardware mode the device will run at. Can be 0-3. > > > > +MAXBUSSPEED is the maximum bus speed in Hertz. > > > > +NO_SPI_DELAY can be 1 or 0. If it is 1, then the lowlevel SPI delay > > > > +will not be performed. This is not standards compliant, but may be > > > > required > > > > +to gain reasonable speeds on embedded hardware. > > > > +CSACTIVELOW can be 1 or 0. If it is 1, the chip is considered to be > > > > selected, if CS > > > > +is at a logical 0. > > > > + > > > > > > Would this be better done via configfs? sysfs files are supposed to be > > > single-value files. > > > > > > Well, I really want to avoid over-engineering this thing. > > I thought about using configfs, but that would require to keep lots of state > > information across the operations. > > So one would have to allocate a device with mkdir. Then configure the > > parameters. > > And then somehow tell the kernel to register it. State has to be maintained > > over > > this time and I'm not sure how that "register" operation would look like. > > Writing a "1" to a "register" file? So why not write all config parameters > > to an "add" file and be done with all the stuff. ;) > > > > It all depends on how you define "one thing per file", IMO. > > This "add" file does one thing. It creates a device. We must, of course, > > pass > > some configuration parameters, too. > > We have precidence with this for the device id being "added" to a driver > at run time in PCI and USB. Not that I really like this, I do think > configfs would be better to do this with here instead of sysfs. > > That being said, as this is a new sysfs file, please break this > documentation up into a file in the Documentation/ABI directory instead > of here. Ok, let us keep this stuff some time in the experimental -mm tree and I will think about configfs again. I don't really like that sysfs "add" file, too. But I can't say if I like configfs more. I probably need to play with configfs a little bit to find out what's best. One advantage is that you can easily add more config stuff later without the risk of breaking stuff. That's quite an advantage, too... But that "how do we register the device after allocating it?" does worry me a little bit. Any ideas on how to implement allocate/config/register in configfs? -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3] Add SPI over GPIO driver
This adds a driver that lets you drive an SPI bus over
generic GPIO pins.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
---
This driver is used in OpenWrt since quite some time, so please
consider for inclusion in mainline.
Simple spelling fixes since v2.
Index: linux-next/include/linux/spi/spi_gpio.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/include/linux/spi/spi_gpio.h 2008-07-20 21:40:38.0
+0200
@@ -0,0 +1,73 @@
+/*
+ * spi_gpio interface to platform code
+ *
+ * Copyright (c) 2008 Piotr Skamruk
+ * Copyright (c) 2008 Michael Buesch
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef _LINUX_SPI_SPI_GPIO
+#define _LINUX_SPI_SPI_GPIO
+
+#include
+#include
+
+
+/**
+ * struct spi_gpio_platform_data - Data definitions for a SPI-GPIO device.
+ *
+ * This structure holds information about a GPIO-based SPI device.
+ *
+ * @pin_clk: The GPIO pin number of the CLOCK pin.
+ *
+ * @pin_miso: The GPIO pin number of the MISO pin.
+ *
+ * @pin_mosi: The GPIO pin number of the MOSI pin.
+ *
+ * @pin_cs: The GPIO pin number of the CHIPSELECT pin.
+ *
+ * @cs_activelow: If true, the chip is selected when the CS line is low.
+ *
+ * @no_spi_delay: If true, no delay is done in the lowlevel bitbanging.
+ *Note that doing no delay is not standards compliant,
+ *but it might be needed to speed up transfers on some
+ *slow embedded machines.
+ *
+ * @boardinfo_setup: This callback is called after the
+ * SPI master device was registered, but before the
+ * device is registered.
+ * @boardinfo_setup_data: Data argument passed to boardinfo_setup().
+ */
+struct spi_gpio_platform_data {
+ unsigned int pin_clk;
+ unsigned int pin_miso;
+ unsigned int pin_mosi;
+ unsigned int pin_cs;
+ bool cs_activelow;
+ bool no_spi_delay;
+ int (*boardinfo_setup)(struct spi_board_info *bi,
+ struct spi_master *master,
+ void *data);
+ void *boardinfo_setup_data;
+};
+
+/**
+ * SPI_GPIO_PLATDEV_NAME - The platform device name string.
+ *
+ * The name string that has to be used for platform_device_alloc
+ * when allocating a spi-gpio device.
+ */
+#define SPI_GPIO_PLATDEV_NAME "spi-gpio"
+
+/**
+ * spi_gpio_next_id - Get another platform device ID number.
+ *
+ * This returns the next platform device ID number that has to be used
+ * for platform_device_alloc. The ID is opaque and should not be used for
+ * anything else.
+ */
+int spi_gpio_next_id(void);
+
+#endif /* _LINUX_SPI_SPI_GPIO */
Index: linux-next/drivers/spi/spi_gpio.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/drivers/spi/spi_gpio.c 2008-07-20 21:40:38.0 +0200
@@ -0,0 +1,251 @@
+/*
+ * Bitbanging SPI bus driver using GPIO API
+ *
+ * Copyright (c) 2008 Piotr Skamruk
+ * Copyright (c) 2008 Michael Buesch
+ *
+ * based on spi_s3c2410_gpio.c
+ * Copyright (c) 2006 Ben Dooks
+ * Copyright (c) 2006 Simtec Electronics
+ * and on i2c-gpio.c
+ * Copyright (C) 2007 Atmel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+struct spi_gpio {
+ struct spi_bitbang bitbang;
+ struct spi_gpio_platform_data *info;
+ struct platform_device *pdev;
+ struct spi_board_info bi;
+};
+
+
+static inline struct spi_gpio *spidev_to_sg(struct spi_device *dev)
+{
+ return dev->controller_data;
+}
+
+static inline void setsck(struct spi_device *dev, int val)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ gpio_set_value(sp->info->pin_clk, val ? 1 : 0);
+}
+
+static inline void setmosi(struct spi_device *dev, int val)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ gpio_set_value(sp->info->pin_mosi, val ? 1 : 0);
+}
+
+static inline u32 getmiso(struct spi_device *dev)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+ return gpio_get_value(sp->info->pin_miso) ? 1 : 0;
+}
+
+static inline void do_spidelay(struct spi_device *dev, unsigned nsecs)
+{
+ struct spi_gpio *sp = spidev_to_sg(dev);
+
+ if (!sp->info->no_spi_delay)
+ ndelay(nsecs);
+}
+
+#define spidelay(nsecs) do { \
+ /* Steal the spi_device pointer from our caller.\
+* The bitbang-API should probably get fixed
[OpenWrt-Devel] [PATCH v3] Add GPIO-based MMC/SD driver
This driver hooks up the mmc_spi and spi_gpio modules so that
MMC/SD cards can be used on a GPIO based bus by bitbanging
the SPI protocol in software.
This driver provides a configfs interface to dynamically create
and destroy GPIO-based MMC/SD card interfaces. It also provides
a platform device interface API.
See Documentation/gpiommc.txt for details.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
---
This driver is used in OpenWrt since quite some time, so please
consider for inclusion in mainline.
Changes since v2: The sysfs interface has been replaced by a configfs interface.
Although I don't really like the bloat this adds (this is a driver for embedded
machines), I do like the much cleaner interface and I think it's worth the
bloat.
Index: linux-next/drivers/mmc/host/gpiommc.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-next/drivers/mmc/host/gpiommc.c 2008-07-20 21:40:47.0
+0200
@@ -0,0 +1,608 @@
+/*
+ * Driver an MMC/SD card on a bitbanging GPIO SPI bus.
+ * This module hooks up the mmc_spi and spi_gpio modules and also
+ * provides a configfs interface.
+ *
+ * Copyright 2008 Michael Buesch <[EMAIL PROTECTED]>
+ *
+ * Licensed under the GNU/GPL. See COPYING for details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define PFX"gpio-mmc: "
+
+
+struct gpiommc_device {
+ struct platform_device *pdev;
+ struct platform_device *spi_pdev;
+ struct spi_board_info boardinfo;
+};
+
+
+MODULE_DESCRIPTION("GPIO based MMC driver");
+MODULE_AUTHOR("Michael Buesch");
+MODULE_LICENSE("GPL");
+
+
+static int gpiommc_boardinfo_setup(struct spi_board_info *bi,
+ struct spi_master *master,
+ void *data)
+{
+ struct gpiommc_device *d = data;
+ struct gpiommc_platform_data *pdata = d->pdev->dev.platform_data;
+
+ /* Bind the SPI master to the MMC-SPI host driver. */
+ strlcpy(bi->modalias, "mmc_spi", sizeof(bi->modalias));
+
+ bi->max_speed_hz = pdata->max_bus_speed;
+ bi->bus_num = master->bus_num;
+ bi->mode = pdata->mode;
+
+ return 0;
+}
+
+static int gpiommc_probe(struct platform_device *pdev)
+{
+ struct gpiommc_platform_data *mmc_pdata = pdev->dev.platform_data;
+ struct spi_gpio_platform_data spi_pdata;
+ struct gpiommc_device *d;
+ int err;
+
+ err = -ENXIO;
+ if (!mmc_pdata)
+ goto error;
+
+#ifdef CONFIG_MMC_SPI_MODULE
+ err = request_module("mmc_spi");
+ if (err) {
+ printk(KERN_WARNING PFX
+ "Failed to request mmc_spi module.\n");
+ }
+#endif /* CONFIG_MMC_SPI_MODULE */
+
+ /* Allocate the GPIO-MMC device */
+ err = -ENOMEM;
+ d = kzalloc(sizeof(*d), GFP_KERNEL);
+ if (!d)
+ goto error;
+ d->pdev = pdev;
+
+ /* Create the SPI-GPIO device */
+ d->spi_pdev = platform_device_alloc(SPI_GPIO_PLATDEV_NAME,
+ spi_gpio_next_id());
+ if (!d->spi_pdev)
+ goto err_free_d;
+
+ memset(&spi_pdata, 0, sizeof(spi_pdata));
+ spi_pdata.pin_clk = mmc_pdata->pins.gpio_clk;
+ spi_pdata.pin_miso = mmc_pdata->pins.gpio_do;
+ spi_pdata.pin_mosi = mmc_pdata->pins.gpio_di;
+ spi_pdata.pin_cs = mmc_pdata->pins.gpio_cs;
+ spi_pdata.cs_activelow = mmc_pdata->pins.cs_activelow;
+ spi_pdata.no_spi_delay = mmc_pdata->no_spi_delay;
+ spi_pdata.boardinfo_setup = gpiommc_boardinfo_setup;
+ spi_pdata.boardinfo_setup_data = d;
+
+ err = platform_device_add_data(d->spi_pdev, &spi_pdata,
+ sizeof(spi_pdata));
+ if (err)
+ goto err_free_pdev;
+ err = platform_device_add(d->spi_pdev);
+ if (err)
+ goto err_free_pdata;
+ platform_set_drvdata(pdev, d);
+
+ printk(KERN_INFO PFX "MMC-Card \"%s\" "
+ "attached to GPIO pins di=%u, do=%u, clk=%u, cs=%u\n",
+ mmc_pdata->name, mmc_pdata->pins.gpio_di,
+ mmc_pdata->pins.gpio_do,
+ mmc_pdata->pins.gpio_clk,
+ mmc_pdata->pins.gpio_cs);
+
+ return 0;
+
+err_free_pdata:
+ kfree(d->spi_pdev->dev.platform_data);
+ d->spi_pdev->dev.platform_data = NULL;
+err_free_pdev:
+ platform_device_put(d->spi_pdev);
+err_free_d:
+ kfree(d);
+error:
+ return err;
+}
+
+static int gpiommc_remove(struct platform_device *pdev)
+{
+ struct gpiommc_device *d = platform_get_drvdata(pdev);
+ struct gpiommc_pla
[OpenWrt-Devel] [PATCH] Add Documentation/ABI/testing/configfs-gpiommc
This adds a Documentation/ABI entry for the gpiommc configfs interface. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: linux-next/Documentation/ABI/testing/configfs-gpiommc === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-next/Documentation/ABI/testing/configfs-gpiommc 2008-07-21 11:43:59.0 +0200 @@ -0,0 +1,9 @@ +What: /config/gpiommc/ +Date: July 2008 +Contact: Michael Buesch <[EMAIL PROTECTED]> +Description: + The /config/gpiommc/ directory consists of a group of + user-managable subdirectories for the dynamic registration + and removal of GPIO based MMC/SD cards. + Complete documentation is available in: + Documentation/gpiommc.txt -- Greetings Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
