[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180620125929.GA8582@apalos>
Date: Wed, 20 Jun 2018 15:59:29 +0300
From: Ilias Apalodimas <ilias.apalodimas@...aro.org>
To: Ivan Vecera <ivecera@...hat.com>
Cc: Jiri Pirko <jiri@...nulli.us>,
Grygorii Strashko <grygorii.strashko@...com>,
netdev@...r.kernel.org, ivan.khoronzhuk@...aro.org, nsekhar@...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 Wed, Jun 20, 2018 at 02:53:47PM +0200, Ivan Vecera wrote:
> On 20.6.2018 09:08, Jiri Pirko wrote:
> > Tue, Jun 19, 2018 at 01:19:00AM CEST, grygorii.strashko@...com wrote:
> >>
> >>
> >> 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 ..
> >
> > ? Why do you say so?
>
> Why aren't they compatible?? You can have devlink binary in initramfs and
> configure the ASIC and ports via devlink batch file - prior mounting NFS root.
This is doable but, are we taking into consideration device reconfiguration
(which was the reason for creating the minimal filesystem) or are we just
talking about device booting/initial config?
>
> >>
> >> 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).
> >
> > You need to study it indeed.
> >
> >>
> >> --
> >> regards,
> >> -grygorii
>
Regards
Ilias
Powered by blists - more mailing lists