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]
Message-ID: <071f7595-aad3-7c16-88ab-8a881d1acf69@ti.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ