lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 17 May 2018 07:51:17 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
        davem@...emloft.net, idosch@...lanox.com,
        jakub.kicinski@...ronome.com, mlxsw@...lanox.com,
        vivien.didelot@...oirfairelinux.com, michael.chan@...adcom.com,
        ganeshgr@...lsio.com, saeedm@...lanox.com,
        simon.horman@...ronome.com, pieter.jansenvanvuuren@...ronome.com,
        john.hurley@...ronome.com, dirk.vandermerwe@...ronome.com,
        alexander.h.duyck@...el.com, ogerlitz@...lanox.com,
        dsahern@...il.com, vijaya.guvva@...ium.com,
        satananda.burla@...ium.com, raghu.vatsavayi@...ium.com,
        felix.manlunas@...ium.com, gospo@...adcom.com,
        sathya.perla@...adcom.com, vasundhara-v.volam@...adcom.com,
        tariqt@...lanox.com, eranbe@...lanox.com,
        jeffrey.t.kirsher@...el.com
Subject: Re: [patch net-next RFC 04/12] dsa: set devlink port attrs for dsa
 ports



On 05/17/2018 07:30 AM, Jiri Pirko wrote:
> Thu, May 17, 2018 at 04:08:10PM CEST, f.fainelli@...il.com wrote:
>>
>>
>> On 05/17/2018 07:02 AM, Jiri Pirko wrote:
>>> Fri, Mar 23, 2018 at 06:09:29PM CET, f.fainelli@...il.com wrote:
>>>> On 03/23/2018 07:49 AM, Jiri Pirko wrote:
>>>>> Fri, Mar 23, 2018 at 02:30:02PM CET, andrew@...n.ch wrote:
>>>>>> On Thu, Mar 22, 2018 at 11:55:14AM +0100, Jiri Pirko wrote:
>>>>>>> From: Jiri Pirko <jiri@...lanox.com>
>>>>>>>
>>>>>>> Set the attrs and allow to expose port flavour to user via devlink.
>>>>>>>
>>>>>>> Signed-off-by: Jiri Pirko <jiri@...lanox.com>
>>>>>>> ---
>>>>>>>  net/dsa/dsa2.c | 23 +++++++++++++++++++++++
>>>>>>>  1 file changed, 23 insertions(+)
>>>>>>>
>>>>>>> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
>>>>>>> index adf50fbc4c13..49453690696d 100644
>>>>>>> --- a/net/dsa/dsa2.c
>>>>>>> +++ b/net/dsa/dsa2.c
>>>>>>> @@ -270,7 +270,27 @@ static int dsa_port_setup(struct dsa_port *dp)
>>>>>>>  	case DSA_PORT_TYPE_UNUSED:
>>>>>>>  		break;
>>>>>>>  	case DSA_PORT_TYPE_CPU:
>>>>>>> +		/* dp->index is used now as port_number. However
>>>>>>> +		 * CPU ports should have separate numbering
>>>>>>> +		 * independent from front panel port numbers.
>>>>>>> +		 */
>>>>>>> +		devlink_port_attrs_set(&dp->devlink_port,
>>>>>>> +				       DEVLINK_PORT_FLAVOUR_CPU,
>>>>>>> +				       dp->index, false, 0);
>>>>>>> +		err = dsa_port_link_register_of(dp);
>>>>>>> +		if (err) {
>>>>>>> +			dev_err(ds->dev, "failed to setup link for port %d.%d\n",
>>>>>>> +				ds->index, dp->index);
>>>>>>> +			return err;
>>>>>>> +		}
>>>>>>
>>>>>> Ah, i get it. These used to be two case statements with one code
>>>>>> block. But you split them apart, so needed to duplicate the
>>>>>> dsa_port_link_register.
>>>>>>
>>>>>> Unfortunately, you forgot to add a 'break;', so it still falls
>>>>>> through, and overwrites the port flavour to DSA.
>>>>>
>>>>> ah, crap. Don't have hw to test this :/
>>>>> Will fix. Thanks!
>>>>
>>>> You don't need hardware, there is drivers/net/dsa/dsa_loop.c which will
>>>> emulate a DSA switch. It won't create interconnect ports, since only one
>>>
>>> Hmm, trying to use dsa_loop. Doing:
>>> modprobe dsa_loop
>>> modprobe fixed_phy
>>>
>>> I don't see the netdevs. Any idea what am I doing wrong? Thanks!
>>
>> Yes, modprobe dsa-loop-bdinfo first, which will create the
> 
> That is compiled inside "fixed_phy", isn't it?

It matches what CONFIG_FIXED_PHY is, so if it's built-in it also becomes
built-in, if is modular, it is also modular, this was fixed with
40013ff20b1beed31184935fc0aea6a859d4d4ef ("net: dsa: Fix functional
dsa-loop dependency on FIXED_PHY")

> In my case, "Module fixed_phy is builtin"
> So it should be enough just to "modprobe dsa_loop", right? That does not
> work :/

There is a caveat that if you have everything modular, if you loaded
fixed_phy first, and forgot to load dsa-loop-bdinfo, then nothing will
happen because the MDIO bus was created and there were no matching devices.

Send me your .config and I will take a look. Attached is mine (64Bit x86
VM), start with:
-- 
Florian

View attachment "x86-64_dsa.config" of type "text/plain" (68968 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ