linux-kernel - Re: [PATCH v3 0/5] phy: core: rework phy_set

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] [day] [month] [year] [list]

Message-ID: <20181217140623.2zze2kfclup7wjti@flea>
Date:   Mon, 17 Dec 2018 15:06:23 +0100
From:   Maxime Ripard <maxime.ripard@...tlin.com>
To:     Grygorii Strashko <grygorii.strashko@...com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Kishon Vijay Abraham I <kishon@...com>,
        Antoine Tenart <antoine.tenart@...e-electrons.com>,
        Quentin Schulz <quentin.schulz@...tlin.com>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>,
        netdev@...r.kernel.org, Sekhar Nori <nsekhar@...com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Tony Lindgren <tony@...mide.com>,
        linux-amlogic@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Vivek Gautam <vivek.gautam@...eaurora.org>,
        Chen-Yu Tsai <wens@...e.org>, Carlo Caione <carlo@...one.org>,
        Chunfeng Yun <chunfeng.yun@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Manu Gautam <mgautam@...eaurora.org>
Subject: Re: [PATCH v3 0/5] phy: core: rework phy_set_mode to accept phy mode
 and submode

Hi Grygorii, Kishon,

On Mon, Nov 19, 2018 at 07:24:19PM -0600, Grygorii Strashko wrote:
> Thank you for your review.
> I've not added "Tested-by"/"Acked-by" tags due to code changes in v3.
> 
> As was discussed in [1] I'm posting series which introduces rework of
> phy_set_mode to accept phy mode and submode. I've dropped TI specific patches as
> this change is pretty big by itself.
> 
> Patch 1 is cumulative change which refactors PHY framework code to
> support dual level PHYs mode configuration - PHY mode and PHY submode. It
> extends .set_mode() callback to support additional parameter "int submode"
> and converts all corresponding PHY drivers to support new .set_mode()
> callback declaration.
> The new extended PHY API
>  int phy_set_mode_ext(struct phy *phy, enum phy_mode mode, int submode)
> is introduced to support dual level PHYs mode configuration and existing
> phy_set_mode() API is converted to macros, so PHY framework consumers do
> not need to be changed (~21 matches).
> 
> Patches 2-4: Add new PHY's mode to be used by Ethernet PHY interface drivers or
> multipurpose PHYs like serdes and convert ocelot-serdes and mvebu-cp110-comphy
> PHY drivers to use recently introduced PHY_MODE_ETHERNET and phy_set_mode_ext().
> 
> Patch 5 - removes unused, ethernet specific phy modes from enum phy_mode.
> 
> Testing:
>  - series tested on TI am335x/am437x/am5(dra7) paltforms.
>  - other driver build tested.

I realise I'm a bit late to the party, but while working on the D-PHY
support, I noticed a few things that could be improved.

I guess the main issue is that the sub-mode is completely opaque to
the generic phy framework now. This might not be a big issue, and I
assume that it has been done that way because the net framework
already has a define for the submode it wants.

However, this creates a bunch of drawbacks at the phy framework level:

 - phy_set_mode will now pass a submode of 0, all the time. This means
   that the behaviour is undefined for all the modes not using the
   submodes at the moment, and phy_interface_t seems to have the value
   PHY_INTERFACE_MODE_NA matching 0, but I guess this could change in
   the future (or the guarantee is not documented anywhere).
 - on a similar note, there's no documentation for which value to pass
   to phy_set_mode_ext when used with something else than a
   PHY_MODE_ETHERNET.
 - at the provider level, if you're supporting a phy that isn't using
   the submodes, you have no way to filter out or reject any subnode,
   since you have no idea what the "no submode" value is.

I guess this can be addressed by:

A) defining a generic phy framework wide unused / invalid phy submode,
that wouldn't collide with the subnode values (such as -1?), and
making phy_set_mode_ext use that.

B) moving the phy submodes definition to the generic phy headers. This
would allow to have a documented, obvious link between a mode and its
subnodes, for all the actors involved (consumer, provider, and
framework) without prior knowledge.

C) Document what the submodes expectations are

What do you think?
Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)