netdev - Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev mode of operation on cpsw driver

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:   Mon, 18 Jun 2018 18:19:00 -0500
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Ilias Apalodimas <ilias.apalodimas@...aro.org>
CC:     <netdev@...r.kernel.org>, <ivan.khoronzhuk@...aro.org>,
        <nsekhar@...com>, <ivecera@...hat.com>, <andrew@...n.ch>,
        <f.fainelli@...il.com>, <francois.ozog@...aro.org>,
        <yogeshs@...com>, <spatton@...com>, <Jose.Abreu@...opsys.com>
Subject: Re: [RFC v2, net-next, PATCH 4/4] net/cpsw_switchdev: add switchdev
 mode of operation on cpsw driver



On 06/14/2018 06:43 AM, Ilias Apalodimas wrote:
> On Thu, Jun 14, 2018 at 01:39:58PM +0200, Jiri Pirko wrote:
>> Thu, Jun 14, 2018 at 01:34:04PM CEST, ilias.apalodimas@...aro.org wrote:
>>> On Thu, Jun 14, 2018 at 01:30:28PM +0200, Jiri Pirko wrote:
>>>> Thu, Jun 14, 2018 at 01:11:30PM CEST, ilias.apalodimas@...aro.org wrote:
>>>>
>>>> [...]
>>>>
>>>>> @@ -2711,6 +2789,10 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
>>>>> 	if (of_property_read_bool(node, "dual_emac"))
>>>>> 		data->switch_mode = CPSW_DUAL_EMAC;
>>>>>
>>>>> +	/* switchdev overrides DTS */
>>>>> +	if (IS_ENABLED(CONFIG_TI_CPSW_SWITCHDEV))
>>>>> +		data->switch_mode = CPSW_SWITCHDEV;
>>>>
>>>> So you force CPSW_SWITCHDEV mode if the CONFIG_TI_CPSW_SWITCHDEV is
>>>> enabled. That does not sound right. I think that user should tell what
>>>> mode does he want regardless what the kernel config is.
>>> We discussed this during the V1 of the RFC. Yes it doesn't seem good, but the
>>> device currently configures the modes using DTS (which is not correct). I choose
>>> the .config due to that. I can't think of anything better, but i am open to
>>> suggestions
>>
>> Agreed that DTS does fit as well. I think that this might be a job for
>> devlink parameters (patchset is going to be sent upstream next week).
>> You do have 1 bus address for the whole device (both ports), right?
>>
> Yes devlink sounds reasonable. I thyink there's only one bus for it, but then
> again i am far from an expert on the hardware interrnals. Grygorii can correct
> me if i am wrong.

Devlink and NFS boot are not compatible as per my understanding, so .. 

Again, current driver, as is, supports NFS boot in all modes
(how good is the cur driver is question which out of scope of this discussion).

And we discussed this in RFC v1 - driver mode selection will be changed 
if we will proceed and it will be new driver for proper switch support.

Not sure about about Devlink (need to study it and we never got any requests from end
users for this as I know), and I'd like to note (again) that this is embedded 
(industrial/automotive etc), so everything preferred to be simple, fast and
preferably configured statically (in most of the cases end users what boot time 
configuration).
 
-- 
regards,
-grygorii