[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHXqBFL-QgKvrvcrjtjSgDdeH9i7Ai86U2ujQ4xpo-vXLEkO5A@mail.gmail.com>
Date: Tue, 12 Jul 2011 17:49:49 +0200
From: Michał Mirosław <mirqus@...il.com>
To: Ben Greear <greearb@...delatech.com>
Cc: netdev@...r.kernel.org
Subject: Re: [RFC v2 2/2] e100: Support RXFCS feature flag.
W dniu 29 czerwca 2011 17:20 użytkownik Ben Greear
<greearb@...delatech.com> napisał:
> On 06/29/2011 08:06 AM, Michał Mirosław wrote:
>> W dniu 29 czerwca 2011 16:35 użytkownik Ben Greear
>> <greearb@...delatech.com> napisał:
>>> On 06/29/2011 07:33 AM, Michał Mirosław wrote:
>>>>
>>>> W dniu 29 czerwca 2011 16:22 użytkownik Ben Greear
>>>> <greearb@...delatech.com> napisał:
[...]
>>>>> I thought 'features' was what the NIC could support, and
>>>>> wanted_features
>>>>> was what the NIC was currently configured to support? I don't want
>>>>> to rx the CRC all the time, just when users enable it...
>>>> hw_features is what device could support, and features is what device
>>>> has currently turned on.
>>> Ok, thanks for that correction.
>>> What does wanted_features mean, then?
>> What user wants to be active. It should be more clear to you if you
>> read the implemetation: netdev_update_features() and friends.
>
> I read it. Seems the code won't let you turn on something not supported,
> so if user wants RXFCS, then wanted_features will have it enabled. So,
> I'm not sure why my e100 patch would be wrong in that case.
wanted_features only reflects what is requested by user, this
combination might be invalid. When conditions change this value
combined with other bits in features are passed through
ndo_fix_features callback and netdev_fix_features() to bring it to
valid state, and then (if resulting set is different than current
features) ndo_set_features() is called to reconfigure device for that
new state change to it.
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists