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
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 kern
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 P
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 t
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
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
> >
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:
>
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.
__
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
> > >
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.
>
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? Curr
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_b
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/
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:
> >> > b
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 ch
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
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
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"
> "5
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 (r
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 s
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_VER
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.
__
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
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 t
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
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:
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
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 contro
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 h
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.
_
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/in
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 G
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
ed 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
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.
> &g
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.
> >
> &
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
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
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.o
/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.3
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 -- pack
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
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 does
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
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 any
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 matt
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
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.
> >>
> >&
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
> buil
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.
>
> Ste
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.
>
> Ste
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
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'
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.
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
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
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.direct
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 p
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.
___
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]
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
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, Mi
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
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 s
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 auto
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 worki
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.
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 sym
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
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.
__
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?
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.
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
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
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 th
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 thr
gt; 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
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-2
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?
> >
> >
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
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 s
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 betwee
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
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 seem
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 wh
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_
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 u
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(
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
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 connec
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
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.
_
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
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_
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/gpi
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
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
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
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 int
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
1 - 100 of 104 matches
Mail list logo
