[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Dec 2023 20:22:10 +0000
From: Simon Horman <horms@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
"Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>,
kuba@...nel.org, pabeni@...hat.com, davem@...emloft.net,
edumazet@...gle.com, jesse.brandeburg@...el.com,
anthony.l.nguyen@...el.com, saeedm@...dia.com, leon@...nel.org,
richardcochran@...il.com, jonathan.lemon@...il.com,
netdev@...r.kernel.org
Subject: Re: [patch net-next] dpll: remove leftover mode_supported() op and
use mode_get() instead
On Sat, Dec 09, 2023 at 11:37:50AM +0100, Jiri Pirko wrote:
> Fri, Dec 08, 2023 at 01:06:34PM CET, vadim.fedorenko@...ux.dev wrote:
> >On 07/12/2023 15:12, Jiri Pirko wrote:
> >> From: Jiri Pirko <jiri@...dia.com>
> >>
> >> Mode supported is currently reported to the user exactly the same, as
> >> the current mode. That's because mode changing is not implemented.
> >> Remove the leftover mode_supported() op and use mode_get() to fill up
> >> the supported mode exposed to user.
> >>
> >> One, if even, mode changing is going to be introduced, this could be
No need to respin, but I guess this should be "if ever".
> >> very easily taken back. In the meantime, prevent drivers form
> >> implementing this in wrong way (as for example recent netdevsim
> >> implementation attempt intended to do).
> >>
> >
> >I'm OK to remove from ptp_ocp part because it's really only one mode
> >supported. But I would like to hear something from Arkadiusz about the
> >plans to maybe implement mode change in ice?
>
> As I wrote in the patch description, if ever there is going
> to be implementation, this could be very easily taken back. Now for
> sure there was already attempt to misimplement this :)
FWIIW, I agree with this reasoning.
Let's add the appropriate API when there is a real user of it.
Reviewed-by: Simon Horman <horms@...nel.org>
...
Powered by blists - more mailing lists