Thu, Oct 15, 2015 at 05:21:22PM CEST, john.fastab...@gmail.com wrote:
>On 15-10-14 10:40 AM, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> Caller should know if he can call attr_set directly (when holding RTNL)
>> or if he has to defer the att_set processing for later.
>>
>>
On 15-10-16 01:23 AM, Jiri Pirko wrote:
> Thu, Oct 15, 2015 at 05:21:22PM CEST, john.fastab...@gmail.com wrote:
>> On 15-10-14 10:40 AM, Jiri Pirko wrote:
>>> From: Jiri Pirko
>>>
>>> Caller should know if he can call attr_set directly (when holding RTNL)
>>> or if he has to
On Fri, Oct 16, 2015 at 1:23 AM, Jiri Pirko wrote:
> Thu, Oct 15, 2015 at 05:21:22PM CEST, john.fastab...@gmail.com wrote:
>>On 15-10-14 10:40 AM, Jiri Pirko wrote:
>>> From: Jiri Pirko
>>>
>>> Caller should know if he can call attr_set directly (when holding
On 15-10-14 10:40 AM, Jiri Pirko wrote:
> From: Jiri Pirko
>
> Caller should know if he can call attr_set directly (when holding RTNL)
> or if he has to defer the att_set processing for later.
>
> This also allows drivers to sleep inside attr_set and report operation
> status
From: Jiri Pirko
Caller should know if he can call attr_set directly (when holding RTNL)
or if he has to defer the att_set processing for later.
This also allows drivers to sleep inside attr_set and report operation
status back to switchdev core. Switchdev core then warns if
On Wed, Oct 14, 2015 at 10:40 AM, Jiri Pirko wrote:
> From: Jiri Pirko
>
> Caller should know if he can call attr_set directly (when holding RTNL)
> or if he has to defer the att_set processing for later.
>
> This also allows drivers to sleep inside attr_set
Thu, Oct 15, 2015 at 06:34:01AM CEST, sfel...@gmail.com wrote:
>On Wed, Oct 14, 2015 at 10:40 AM, Jiri Pirko wrote:
>> From: Jiri Pirko
>>
>> Caller should know if he can call attr_set directly (when holding RTNL)
>> or if he has to defer the att_set