On Wednesday 05 June 2013, Solomon Peachy wrote:
> > Regarding a long-term solution, I think what we should do here is to
> > move the reset logic into the SDIO framework itself: We have similar
> > requirements even for eMMC and SD cards, where you need to provide
> > the correct voltage to a
On Wednesday 05 June 2013, Solomon Peachy wrote:
Regarding a long-term solution, I think what we should do here is to
move the reset logic into the SDIO framework itself: We have similar
requirements even for eMMC and SD cards, where you need to provide
the correct voltage to a device on
On Mon, Jun 03, 2013 at 10:40:42AM +0200, Arnd Bergmann wrote:
> It's much better than what you have today, but not ideal because it
> means the driver cannot be a loadable module any more.
At least not when being built with platform data, anyway.
I suppose the next step here is to define some
On Mon, Jun 03, 2013 at 10:40:42AM +0200, Arnd Bergmann wrote:
It's much better than what you have today, but not ideal because it
means the driver cannot be a loadable module any more.
At least not when being built with platform data, anyway.
I suppose the next step here is to define some
On Sunday 02 June 2013 10:47:26 Solomon Peachy wrote:
> On Sun, Jun 02, 2013 at 03:59:12PM +0200, Arnd Bergmann wrote:
> > The driver doesn't reliably build, and I'm trying to fix it.
> > From my perspective, we can just mark it 'depends on !ARM'
> > to get it off my radar, but other people are
On Sunday 02 June 2013 10:47:26 Solomon Peachy wrote:
On Sun, Jun 02, 2013 at 03:59:12PM +0200, Arnd Bergmann wrote:
The driver doesn't reliably build, and I'm trying to fix it.
From my perspective, we can just mark it 'depends on !ARM'
to get it off my radar, but other people are doing
On Sun, Jun 2, 2013 at 4:47 PM, Solomon Peachy wrote:
>> In fact my mobile phone has a cw1200 chip that was working until
>> recently. Now it just crashes when I do 'ifconfig wlan0 up'
>> or enable WLAN in the Android settings menu. :(
>>
>> I'm not blaming you for that ;-)
>
> What model, out
On Sun, Jun 02, 2013 at 03:59:12PM +0200, Arnd Bergmann wrote:
> The driver doesn't reliably build, and I'm trying to fix it.
> From my perspective, we can just mark it 'depends on !ARM'
> to get it off my radar, but other people are doing build
> testing on x86 and will run into the same issues.
On Sunday 02 June 2013 08:29:54 Solomon Peachy wrote:
> On Sun, Jun 02, 2013 at 12:37:21AM +0200, Arnd Bergmann wrote:
> > I got compile errors with the cw1200, which has lead me to take a
> > closer look. It seems the driver still has a number of issues,
> > and this addresses some of them and
On Sun, Jun 02, 2013 at 08:29:54AM -0400, Solomon Peachy wrote:
> > * Add comments about passing GPIO numbers in platform_data:
> > You should not use IORESOURCE_IO, which is for legacy ISA
> > I/O ports on PCs, not for GPIOs.
>
> Fair enough. The use of resources was something already in
On Sun, Jun 02, 2013 at 12:37:21AM +0200, Arnd Bergmann wrote:
> I got compile errors with the cw1200, which has lead me to take a
> closer look. It seems the driver still has a number of issues,
> and this addresses some of them and marks others as FIXME:
In short, NACK, at least not as posted.
On Sun, Jun 02, 2013 at 12:37:21AM +0200, Arnd Bergmann wrote:
I got compile errors with the cw1200, which has lead me to take a
closer look. It seems the driver still has a number of issues,
and this addresses some of them and marks others as FIXME:
In short, NACK, at least not as posted.
On Sun, Jun 02, 2013 at 08:29:54AM -0400, Solomon Peachy wrote:
* Add comments about passing GPIO numbers in platform_data:
You should not use IORESOURCE_IO, which is for legacy ISA
I/O ports on PCs, not for GPIOs.
Fair enough. The use of resources was something already in the driver
On Sunday 02 June 2013 08:29:54 Solomon Peachy wrote:
On Sun, Jun 02, 2013 at 12:37:21AM +0200, Arnd Bergmann wrote:
I got compile errors with the cw1200, which has lead me to take a
closer look. It seems the driver still has a number of issues,
and this addresses some of them and marks
On Sun, Jun 02, 2013 at 03:59:12PM +0200, Arnd Bergmann wrote:
The driver doesn't reliably build, and I'm trying to fix it.
From my perspective, we can just mark it 'depends on !ARM'
to get it off my radar, but other people are doing build
testing on x86 and will run into the same issues.
On Sun, Jun 2, 2013 at 4:47 PM, Solomon Peachy pi...@shaftnet.org wrote:
In fact my mobile phone has a cw1200 chip that was working until
recently. Now it just crashes when I do 'ifconfig wlan0 up'
or enable WLAN in the Android settings menu. :(
I'm not blaming you for that ;-)
What model,
I got compile errors with the cw1200, which has lead me to take a
closer look. It seems the driver still has a number of issues,
and this addresses some of them and marks others as FIXME:
* The cw1200_sagrad.c file should not be there, hardcoding
hardware configuration in .c files has been
I got compile errors with the cw1200, which has lead me to take a
closer look. It seems the driver still has a number of issues,
and this addresses some of them and marks others as FIXME:
* The cw1200_sagrad.c file should not be there, hardcoding
hardware configuration in .c files has been
18 matches
Mail list logo
