> > OK I think I finally see what you are saying. Sorry it took me this
> > long. I do not mean to be difficult, I just want to understand.
Not a problem. This is a bit different to normal, the complexity of
the stack means you need to handle this different to most drivers. If
you have done any de
On Sat Nov 28, 2020 at 6:38 PM CET, Andrew Lunn wrote:
> > > OK I think I finally see what you are saying. Sorry it took me this
> > > long. I do not mean to be difficult, I just want to understand.
>
> Not a problem. This is a bit different to normal, the complexity of
> the stack means you need t
On 11/27/2020 3:19 PM, Tobias Waldekranz wrote:
>> The initial design of switchdev was transactions. First there was a
>> prepare call, where you validated the requested action is possible,
>> and allocate resources needed, but don't actually do it. This prepare
>> call is allowed to fail. Then
On Fri, Nov 27, 2020 at 17:28, Andrew Lunn wrote:
>> This is a digression, but I really do not get this shift from using
>> BUG()s to WARN()s in the kernel when you detect a violated invariant. It
>> smells of "On Error Resume Next" to me.
>
> A WARN() gives you a chance to actually use the machin
> This is a digression, but I really do not get this shift from using
> BUG()s to WARN()s in the kernel when you detect a violated invariant. It
> smells of "On Error Resume Next" to me.
A WARN() gives you a chance to actually use the machine to collect
logs, the kernel dump, etc. You might be abl
On Thu, Nov 26, 2020 at 23:57, Andrew Lunn wrote:
>> If you go with the static array, you theoretically can not get the
>> equivalent of an ENOMEM. Practically though you have to iterate through
>> the array and look for a free entry, but you still have to put a return
>> statement at the bottom o
> If you go with the static array, you theoretically can not get the
> equivalent of an ENOMEM. Practically though you have to iterate through
> the array and look for a free entry, but you still have to put a return
> statement at the bottom of that function, right? Or panic I suppose. My
> guess
On Fri, Nov 20, 2020 at 14:30, Andrew Lunn wrote:
> On Thu, Nov 19, 2020 at 06:43:38PM -0800, Florian Fainelli wrote:
>> >
>> > Hi Tobias
>> >
>> > My comment last time was to statically allocated them at probe
>> > time. Worse case scenario is each port is alone in a LAG. Pointless,
>> > but so
On Thu, Nov 19, 2020 at 06:43:38PM -0800, Florian Fainelli wrote:
>
>
> On 11/19/2020 4:30 PM, Andrew Lunn wrote:
> >> +static struct dsa_lag *dsa_lag_get(struct dsa_switch_tree *dst,
> >> + struct net_device *dev)
> >> +{
> >> + unsigned long busy = 0;
> >> + struct
On 11/19/2020 4:30 PM, Andrew Lunn wrote:
>> +static struct dsa_lag *dsa_lag_get(struct dsa_switch_tree *dst,
>> + struct net_device *dev)
>> +{
>> +unsigned long busy = 0;
>> +struct dsa_lag *lag;
>> +int id;
>> +
>> +list_for_each_entry(lag, &dst->
> +static struct dsa_lag *dsa_lag_get(struct dsa_switch_tree *dst,
> +struct net_device *dev)
> +{
> + unsigned long busy = 0;
> + struct dsa_lag *lag;
> + int id;
> +
> + list_for_each_entry(lag, &dst->lags, list) {
> + set_bit(lag->id, &
Monitor the following events and notify the driver when:
- A DSA port joins/leaves a LAG.
- A LAG, made up of DSA ports, joins/leaves a bridge.
- A DSA port in a LAG is enabled/disabled (enabled meaning
"distributing" in 802.3ad LACP terms).
Each LAG interface to which a DSA port is attached is
12 matches
Mail list logo
