headers
Luis R. Rodriguez | 1 Sep 01:05
Picon
Gravatar

Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)

On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@...> wrote:
> On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@...> wrote:
>> Hi Luis,
>>
>>> > OK not so bad except for:
>>> >
>>> > > kernel/net/wimax/wimax.ko
>>> >
>>> > That's touching another subsystem but we could technically merge wimax
>>> > into compat-wireless if Inaky thinks that's a good idea. the point
>>> > here is to unify anything that uses rfkill for backport usage.
>>>
>>> Oh boy, can of worms
>>>
>>> I have my own compat-wimax already, which already handles things for
>>> backwards compat (many #ifdef hacks to simplify life) and which is
>>> heavily used internally.
>>>
>>> I don't really know how much worth it might be and I know I don't have
>>> resources to support both.
>>
>> for the wireless-compat tree, I would just remove the RFKILL support for
>> WiMAX. It is really not worth to support it.
>
> Works for me, we then still need to address (if we really care) the
> platform stuff. If someone is interested feel free to send patches to
> add those, I figure as long we get down to the latest supported stable
> kernel it should be good. The latest supported stable kernel is always
> on display on kernel,org, today being 2.6.27.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Inaky Perez-Gonzalez | 1 Sep 01:10
Picon
Favicon

Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)

On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@...> wrote:
> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@...> wrote:
> >> Hi Luis,
> >>
> >>> > OK not so bad except for:
> >>> >
> >>> > > kernel/net/wimax/wimax.ko
> >>> >
> >>> > That's touching another subsystem but we could technically merge wimax
> >>> > into compat-wireless if Inaky thinks that's a good idea. the point
> >>> > here is to unify anything that uses rfkill for backport usage.
> >>>
> >>> Oh boy, can of worms
> >>>
> >>> I have my own compat-wimax already, which already handles things for
> >>> backwards compat (many #ifdef hacks to simplify life) and which is
> >>> heavily used internally.
> >>>
> >>> I don't really know how much worth it might be and I know I don't have
> >>> resources to support both.
> >>
> >> for the wireless-compat tree, I would just remove the RFKILL support for
> >> WiMAX. It is really not worth to support it.
> >
> > Works for me, we then still need to address (if we really care) the
> > platform stuff. If someone is interested feel free to send patches to
> > add those, I figure as long we get down to the latest supported stable
> > kernel it should be good. The latest supported stable kernel is always
> > on display on kernel,org, today being 2.6.27.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gábor Stefanik | 1 Sep 01:11
Picon

Re: zd1211rw on ppc (iBook G4)

(Restoring CCs from original message.)

2009/9/1 Hin-Tak Leung <hintak.leung@...>:
> 2009/8/31 Gábor Stefanik <netrolller.3d@...>:
>> On Mon, Aug 31, 2009 at 9:35 PM, Hin-Tak Leung<hintak.leung@...m> wrote:
>>> On Mon, Aug 31, 2009 at 8:27 PM, Michael Buesch<mb@...> wrote:
>>>> On Monday 31 August 2009 20:26:22 Hin-Tak Leung wrote:
>>>>> It would appear that the rw driver's ieee80211->mac80211 conversion
>>>>> has broken big- endian platforms, at a first guess.
>>>>
>>>> Last time I tested the device worked fine on my powerbook with zd1211rw/mac80211.
>>>> But that's maybe two or three release cycles in the past.
>>>>
>>>> --
>>>> Greetings, Michael.
>>>>
>>>
>>> The rw ieee80211->mac80211 conversion happens in 2.6.27->26.28 ...
>>> Iguess the question is whether it was 2.6.28 or 2.6.27 you had success
>>> with? That's unfortunately two *and* three cycles in the past,
>>> respectively :-).
>>
>> I seem to remember that the conversion happened between 2.6.24 and
>> 2.6.25 - the 2.6.26 injection patch on patches.aircrack-ng.org is also
>> clearly for the mac80211 version.
>
> Some part persists till 2.6.28 - I was running git diff between
> different tags like this:
>
> git diff v2.6.27:drivers/net/wireless/zd1211rw/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hin-Tak Leung | 1 Sep 01:16
Picon

Re: rtl8187b Problem with tx level

2009/8/31 Larry Finger <Larry.Finger@...>:
> Gábor Stefanik wrote:
>>
>> The driver is not actually closed-source; they just don't provide any
>> drivers on their site anymore, instead they send their reference
>> drivers to OEMs, expecting the OEMs to release their own versions
>> (with sources - most vendors who do release Linux drivers in fact only
>> release sources, without binaries). The reason for this appears to be
>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>> with modified USB IDs. (Or are you seeing a binary-only driver on
>> realtek.com.tw? That would definitely be a GPL violation, given that
>> they use a modified version of the GPLed libipw stack.)
>
>
> No driver at all. I looked at the Toshiba site, but found only Windows
> drivers. Which OEM has the driver available?
>
> Larry

The r8187 is distributed from OEMs - stand to reason, as realtek don't
really sell their own brand on high-street shops? We got one release
e-mailed to us, and there are a few floating around on the internet
under some laptop or usb hardware vendors. It is available under this,
for example: http://service.one.de/index.php?&direction=0&order=&directory=NOTEBOOKS/ONE_A1XX/LINUX/Source-code/Wireless
r8187mesh is the one in the mesh directory.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 3 comments |
headers
Luis R. Rodriguez | 1 Sep 01:34
Picon
Gravatar

Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)

On Mon, Aug 31, 2009 at 4:10 PM, Inaky
Perez-Gonzalez<inaky.perez-gonzalez@...> wrote:
> On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote:
>> On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@...> wrote:
>> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@...> wrote:
>> >> Hi Luis,
>> >>
>> >>> > OK not so bad except for:
>> >>> >
>> >>> > > kernel/net/wimax/wimax.ko
>> >>> >
>> >>> > That's touching another subsystem but we could technically merge wimax
>> >>> > into compat-wireless if Inaky thinks that's a good idea. the point
>> >>> > here is to unify anything that uses rfkill for backport usage.
>> >>>
>> >>> Oh boy, can of worms
>> >>>
>> >>> I have my own compat-wimax already, which already handles things for
>> >>> backwards compat (many #ifdef hacks to simplify life) and which is
>> >>> heavily used internally.
>> >>>
>> >>> I don't really know how much worth it might be and I know I don't have
>> >>> resources to support both.
>> >>
>> >> for the wireless-compat tree, I would just remove the RFKILL support for
>> >> WiMAX. It is really not worth to support it.
>> >
>> > Works for me, we then still need to address (if we really care) the
>> > platform stuff. If someone is interested feel free to send patches to
>> > add those, I figure as long we get down to the latest supported stable
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luis R. Rodriguez | 1 Sep 01:37
Picon
Gravatar

Re: rtl8187b Problem with tx level

2009/8/31 Gábor Stefanik <netrolller.3d@...>:
> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger <at> lwfinger.net> wrote:
>> Hin-Tak Leung wrote:
>>>
>>> I just took a look at the history - there aren't obvious bug fixes, a
>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>> would affect tx level beyond 2.6.31-rc7, I think.
>>
>> Your analysis matches my recollection.
>>
>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>> these days. There are no sources for the B on their web site. In
>> addition, the one that Tobias loaded tainted his kernel.
>>
>> Larry
>
> The driver is not actually closed-source; they just don't provide any
> drivers on their site anymore, instead they send their reference
> drivers to OEMs, expecting the OEMs to release their own versions
> (with sources - most vendors who do release Linux drivers in fact only
> release sources, without binaries). The reason for this appears to be
> that Realtek now encourages vendors to sell RTL81xx wireless chips
> with modified USB IDs. (Or are you seeing a binary-only driver on
> realtek.com.tw? That would definitely be a GPL violation, given that
> they use a modified version of the GPLed libipw stack.)

Gabor, do you speak to RealkTek folks? It seems what may be best for
OEMs and RealTek themselves is to post drivers for inclusion into
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gábor Stefanik | 1 Sep 01:46
Picon

Re: rtl8187b Problem with tx level

On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<mcgrof@...> wrote:
> 2009/8/31 Gábor Stefanik <netrolller.3d@...>:
>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger <at> lwfinger.net> wrote:
>>> Hin-Tak Leung wrote:
>>>>
>>>> I just took a look at the history - there aren't obvious bug fixes, a
>>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>>> would affect tx level beyond 2.6.31-rc7, I think.
>>>
>>> Your analysis matches my recollection.
>>>
>>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>>> these days. There are no sources for the B on their web site. In
>>> addition, the one that Tobias loaded tainted his kernel.
>>>
>>> Larry
>>
>> The driver is not actually closed-source; they just don't provide any
>> drivers on their site anymore, instead they send their reference
>> drivers to OEMs, expecting the OEMs to release their own versions
>> (with sources - most vendors who do release Linux drivers in fact only
>> release sources, without binaries). The reason for this appears to be
>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>> with modified USB IDs. (Or are you seeing a binary-only driver on
>> realtek.com.tw? That would definitely be a GPL violation, given that
>> they use a modified version of the GPLed libipw stack.)
>
> Gabor, do you speak to RealkTek folks? It seems what may be best for
(Continue reading)

Permalink | Reply | 2 comments |
headers
Luis R. Rodriguez | 1 Sep 01:54
Picon
Gravatar

Re: memleaks, acpi + ext4 + tty

On Mon, Aug 31, 2009 at 1:02 PM, Luis R. Rodriguez<mcgrof <at> gmail.com> wrote:
> On Mon, Aug 31, 2009 at 12:47 PM, John W.
> Linville<linville <at> tuxdriver.com> wrote:
>> On Mon, Aug 31, 2009 at 12:43:01PM -0700, Luis R. Rodriguez wrote:
>>> On Mon, Aug 31, 2009 at 12:33 PM, John W.
>>> Linville<linville <at> tuxdriver.com> wrote:
>>
>>> > My guess is that the culprit is between
>>> > v2.6.31-rc8 and whatever is at the head of linux-2.6-allstable.
>>>
>>> But the issue is *not* in linux-2.6-allstable, it is only present on
>>> wireless-testing, and I went as far back as merge-2009-08-28. I was
>>> using whatever tag was available prior to you moving to rc8, and that
>>> worked.
>>
>> OK, then I can only guess that something went wrong in your bisection
>> (e.g. dirty build, something not marked properly, etc).
>
> Well so remember I did a clean git clone of wireless-testing and the
> issue was still there, but I determined just now it seems rc8 from
> Linus does indeed also have the issue. For some reason the issue was
> not present on hpa's rc8 on linux-2.6-allstable. Will double check on
> that again.

OK so hpa's tree just had all of Linus' stuff pulled, not just rc8. It
turns out Eric Paris' inotify patches are required to fix 2.6.31-rc8
for me.. I tested just one patch and it fixed my bootup lag:

http://git.infradead.org/users/eparis/notify.git/commit/b962e7312ae87006aed6f68ceee94bdf8db08338
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luis R. Rodriguez | 1 Sep 01:56
Picon
Gravatar

Re: rtl8187b Problem with tx level

2009/8/31 Gábor Stefanik <netrolller.3d@...>:
> On Tue, Sep 1, 2009 at 1:37 AM, Luis R. Rodriguez<mcgrof@...> wrote:
>> 2009/8/31 Gábor Stefanik <netrolller.3d@...>:
>>> On Mon, Aug 31, 2009 at 11:10 PM, Larry Finger<Larry.Finger <at> lwfinger.net> wrote:
>>>> Hin-Tak Leung wrote:
>>>>>
>>>>> I just took a look at the history - there aren't obvious bug fixes, a
>>>>> bunch of work queue-related changes from you & Johannes; feature-wise,
>>>>> Larry added LED blinking after 2.6.30, and Herton added rfkill support
>>>>> quite recently after 2.6.31-rc7 . But no, there isn't any change that
>>>>> would affect tx level beyond 2.6.31-rc7, I think.
>>>>
>>>> Your analysis matches my recollection.
>>>>
>>>> Apparently RealTek is supplying a closed-source driver for RTL8187B
>>>> these days. There are no sources for the B on their web site. In
>>>> addition, the one that Tobias loaded tainted his kernel.
>>>>
>>>> Larry
>>>
>>> The driver is not actually closed-source; they just don't provide any
>>> drivers on their site anymore, instead they send their reference
>>> drivers to OEMs, expecting the OEMs to release their own versions
>>> (with sources - most vendors who do release Linux drivers in fact only
>>> release sources, without binaries). The reason for this appears to be
>>> that Realtek now encourages vendors to sell RTL81xx wireless chips
>>> with modified USB IDs. (Or are you seeing a binary-only driver on
>>> realtek.com.tw? That would definitely be a GPL violation, given that
>>> they use a modified version of the GPLed libipw stack.)
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Inaky Perez-Gonzalez | 1 Sep 02:09
Picon
Favicon

Re: hal, rfkill and compat-wireless (Re: [RFC/RFT] rtl8187: Implement rfkill support)

On Mon, 2009-08-31 at 17:34 -0600, Luis R. Rodriguez wrote:
> On Mon, Aug 31, 2009 at 4:10 PM, Inaky
> Perez-Gonzalez<inaky.perez-gonzalez@...> wrote:
> > On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote:
> >> On Mon, Aug 31, 2009 at 2:45 PM, Luis R.
Rodriguez<mcgrof@...> wrote:
> >> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel
Holtmann<marcel@...> wrote:
> >> >> Hi Luis,
> >> >>
> >> >>> > OK not so bad except for:
> >> >>> >
> >> >>> > > kernel/net/wimax/wimax.ko
> >> >>> >
> >> >>> > That's touching another subsystem but we could technically merge wimax
> >> >>> > into compat-wireless if Inaky thinks that's a good idea. the point
> >> >>> > here is to unify anything that uses rfkill for backport usage.
> >> >>>
> >> >>> Oh boy, can of worms
> >> >>>
> >> >>> I have my own compat-wimax already, which already handles things for
> >> >>> backwards compat (many #ifdef hacks to simplify life) and which is
> >> >>> heavily used internally.
> >> >>>
> >> >>> I don't really know how much worth it might be and I know I don't have
> >> >>> resources to support both.
> >> >>
> >> >> for the wireless-compat tree, I would just remove the RFKILL support for
> >> >> WiMAX. It is really not worth to support it.
> >> >
(Continue reading)

Permalink | Reply | 0 comments |

Gmane