[Vivid][PATCH] UBUNTU: SAUCE: mwifiex: Switch WiFi LED state according to the device status

[Jesse Sung]

2015-11-06 13:37 GMT+08:00 Keng-Yu Lin <kengyu at canonical.com>:
> Hi Seth,
>   For btusb, what if we move it to ubuntu/ and modify it only to match
> this specific VID/PID? If you think this will be good, just let us
> know. Jesse will work on a V2 patch in this way.
>
>   For the wifi led, the patch is from the Marvell BSP directly. IMHO
> we better leave it as what it is. There may be chances that we may
> have to merge/cherry-pick some patches if Marvell releases a new
> version of BSP.
>
>   Some background: the two patches are not for the coming SRU. They
> are for the re-spin of the last SRU.
>
>
> On Fri, Nov 6, 2015 at 1:13 AM, Seth Forshee <seth.forshee at canonical.com> wrote:
>> On Fri, Nov 06, 2015 at 12:47:54AM +0800, Jesse Sung wrote:
>>> 2015-11-05 22:45 GMT+08:00 Seth Forshee <seth.forshee at canonical.com>:
>>> > On Thu, Nov 05, 2015 at 05:45:07PM +0800, Jesse Sung wrote:
>>> >> 2015-11-05 0:21 GMT+08:00 Seth Forshee <seth.forshee at canonical.com>:
>>> >> > On Wed, Nov 04, 2015 at 08:27:53PM +0800, Wen-chien Jesse Sung wrote:
>>> >> >> BugLink: https://launchpad.net/bugs/1512997
>>> >> >>
>>> >> >> For Edge Gateway 5000/5100 only.
>>> >> >>
>>> >> >> Add code for controlling WiFi LED via firmware, and turns the LED on
>>> >> >> and off when the interface is up and down accordingly.
>>> >> >>
>>> >> >> Signed-off-by: Wen-chien Jesse Sung <jesse.sung at canonical.com>
>>> >> >> Tested-by: Gavin Lin <gavin.lin at canonical.com>
>>> >> >> Reviewed-by: Keng-Yu Lin <kengyu at canonical.com>
>>> >> >
>>> >> > mac80211 already has led-trigger support for this sort of thing. Is
>>> >> > there some reason that can't be utilized instead of hacking up the
>>> >> > driver like this?
>>> >>
>>> >> Humm.. This patch is based on a solution provided by Marvell.
>>> >> If led_trigger is preferred, I'll work on it.
>>> >
>>> > I'm not sure whether or not the LED integration in mac80211 can provide
>>> > what you want or not, I just wanted to know if you had considered it.
>>> > If it doesn't then I don't have any big objections to the mwifiex
>>> > changes, though I'm not crazy about the DMI stuff.

Since mwifiex is using FullMAC instead of mac80211, we can't use the led-trigger
support in mac80211 in this case.

>>>
>>> I'll look into it and see it can be done with led_trigger.
>>>
>>> > The btusb changes are more troublesome though because that's a very
>>> > generic driver, not hardware-specific like mwifiex.
>>>
>>> All of the changes in btusb would not have effect if it's not run on
>>> Edge Gateway.
>>> is_edge_gateway in btusb_data would only be set when the dmi_match() returns
>>> true, and new code executes only when is_edge_gateway is true.
>>
>> Fine, but if we were to start doing this for multiple hardware problems
>> then it quickly gets very messy, and it also creates more conflicts for
>> backports. If the LED framework turns out to be appropriate for your
>> needs then it could alleviate both of these problems.

Since bluetooth stack doesn't do any led-trigger calls, we need to call
functions to toggle LED in btusb anyway, no matter it is done directly or
via LED framworks.

To prevent conflicts for later backports, we may have a duplicate btusb
in ubuntu/ matching VID/PID only for this module, just like what Kengyu
suggested. But this also means that if there's any fix for btusb, it may need
to be applied to both files, which introduces a different problem of
maintenance.

>>
>> Seth

Thanks,
Jesse