| 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
| ||
|
Message-ID: <20181213204234.63hr74etgxvhnmhy@valkosipuli.retiisi.org.uk>
Date: Thu, 13 Dec 2018 22:42:34 +0200
From: sakari.ailus@....fi
To: Maxime Ripard <maxime.ripard@...tlin.com>
Cc: Kishon Vijay Abraham I <kishon@...com>,
Boris Brezillon <boris.brezillon@...tlin.com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
linux-media@...r.kernel.org,
Archit Taneja <architt@...eaurora.org>,
Andrzej Hajda <a.hajda@...sung.com>,
Chen-Yu Tsai <wens@...e.org>, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org,
Krzysztof Witos <kwitos@...ence.com>,
Rafal Ciepiela <rafalc@...ence.com>
Subject: Re: [PATCH v3 02/10] phy: Add configuration interface
Hi Maxime,
On Fri, Dec 07, 2018 at 02:55:29PM +0100, Maxime Ripard wrote:
> The phy framework is only allowing to configure the power state of the PHY
> using the init and power_on hooks, and their power_off and exit
> counterparts.
>
> While it works for most, simple, PHYs supported so far, some more advanced
> PHYs need some configuration depending on runtime parameters. These PHYs
> have been supported by a number of means already, often by using ad-hoc
> drivers in their consumer drivers.
>
> That doesn't work too well however, when a consumer device needs to deal
> with multiple PHYs, or when multiple consumers need to deal with the same
> PHY (a DSI driver and a CSI driver for example).
>
> So we'll add a new interface, through two funtions, phy_validate and
> phy_configure. The first one will allow to check that a current
> configuration, for a given mode, is applicable. It will also allow the PHY
> driver to tune the settings given as parameters as it sees fit.
>
> phy_configure will actually apply that configuration in the phy itself.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@...tlin.com>
> ---
> drivers/phy/phy-core.c | 64 ++++++++++++++++++++++++++++++++++++++++++-
> include/linux/phy/phy.h | 58 ++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 122 insertions(+)
>
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index df3d4ba516ab..19b05e824ee4 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -408,6 +408,70 @@ int phy_calibrate(struct phy *phy)
> EXPORT_SYMBOL_GPL(phy_calibrate);
>
> /**
> + * phy_configure() - Changes the phy parameters
> + * @phy: the phy returned by phy_get()
> + * @opts: New configuration to apply
> + *
> + * Used to change the PHY parameters. phy_init() must have been called
> + * on the phy. The configuration will be applied on the current phy
> + * mode, that can be changed using phy_set_mode().
> + *
> + * Returns: 0 if successful, an negative error code otherwise
> + */
> +int phy_configure(struct phy *phy, union phy_configure_opts *opts)
> +{
> + int ret;
> +
> + if (!phy)
> + return -EINVAL;
> +
> + if (!phy->ops->configure)
> + return -EOPNOTSUPP;
> +
> + mutex_lock(&phy->mutex);
> + ret = phy->ops->configure(phy, opts);
> + mutex_unlock(&phy->mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_configure);
> +
> +/**
> + * phy_validate() - Checks the phy parameters
> + * @phy: the phy returned by phy_get()
> + * @mode: phy_mode the configuration is applicable to.
> + * @submode: PHY submode the configuration is applicable to.
> + * @opts: Configuration to check
> + *
> + * Used to check that the current set of parameters can be handled by
> + * the phy. Implementations are free to tune the parameters passed as
> + * arguments if needed by some implementation detail or
> + * constraints. It will not change any actual configuration of the
> + * PHY, so calling it as many times as deemed fit will have no side
> + * effect.
> + *
> + * Returns: 0 if successful, an negative error code otherwise
> + */
> +int phy_validate(struct phy *phy, enum phy_mode mode, int submode,
> + union phy_configure_opts *opts)
> +{
> + int ret;
> +
> + if (!phy)
> + return -EINVAL;
> +
> + if (!phy->ops->validate)
> + return -EOPNOTSUPP;
> +
> + mutex_lock(&phy->mutex);
> + ret = phy->ops->validate(phy, mode, submode, opts);
> + mutex_unlock(&phy->mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_validate);
> +
> +/**
> * _of_phy_get() - lookup and obtain a reference to a phy by phandle
> * @np: device_node for which to get the phy
> * @index: the index of the phy
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 453f21834685..04476c026b5a 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -43,6 +43,12 @@ enum phy_mode {
> };
>
> /**
> + * union phy_configure_opts - Opaque generic phy configuration
> + */
> +union phy_configure_opts {
> +};
> +
> +/**
> * struct phy_ops - set of function pointers for performing phy operations
> * @init: operation to be performed for initializing phy
> * @exit: operation to be performed while exiting
> @@ -59,6 +65,37 @@ struct phy_ops {
> int (*power_on)(struct phy *phy);
> int (*power_off)(struct phy *phy);
> int (*set_mode)(struct phy *phy, enum phy_mode mode, int submode);
> +
> + /**
> + * @configure:
> + *
> + * Optional.
> + *
> + * Used to change the PHY parameters. phy_init() must have
> + * been called on the phy.
> + *
> + * Returns: 0 if successful, an negative error code otherwise
> + */
> + int (*configure)(struct phy *phy, union phy_configure_opts *opts);
> +
> + /**
> + * @validate:
> + *
> + * Optional.
> + *
> + * Used to check that the current set of parameters can be
> + * handled by the phy. Implementations are free to tune the
> + * parameters passed as arguments if needed by some
> + * implementation detail or constraints. It must not change
> + * any actual configuration of the PHY, so calling it as many
> + * times as deemed fit by the consumer must have no side
> + * effect.
> + *
> + * Returns: 0 if the configuration can be applied, an negative
> + * error code otherwise
I think it'd be good to document which error codes can be returned and what
do they mean. I'm no expert in the PHY framework, but it seems the caller
would need to be able to cope with -EOPNOTSUPP for instance, which may not
necessarily signal an error at all.
Would it be enough to document the PHY framework interface functions rather
than the ops at this level? There seems to be a non-zero chances of the two
descriptions of diverging. Just an idea.
> + */
> + int (*validate)(struct phy *phy, enum phy_mode mode, int submode,
> + union phy_configure_opts *opts);
> int (*reset)(struct phy *phy);
> int (*calibrate)(struct phy *phy);
> struct module *owner;
> @@ -165,6 +202,9 @@ int phy_power_off(struct phy *phy);
> int phy_set_mode_ext(struct phy *phy, enum phy_mode mode, int submode);
> #define phy_set_mode(phy, mode) \
> phy_set_mode_ext(phy, mode, 0)
> +int phy_configure(struct phy *phy, union phy_configure_opts *opts);
> +int phy_validate(struct phy *phy, enum phy_mode mode, int submode,
> + union phy_configure_opts *opts);
>
> static inline enum phy_mode phy_get_mode(struct phy *phy)
> {
> @@ -309,6 +349,24 @@ static inline int phy_calibrate(struct phy *phy)
> return -ENOSYS;
> }
>
> +static inline int phy_configure(struct phy *phy,
> + union phy_configure_opts *opts)
> +{
> + if (!phy)
> + return 0;
> +
> + return -ENOSYS;
> +}
> +
> +static inline int phy_validate(struct phy *phy, enum phy_mode mode, int submode,
> + union phy_configure_opts *opts)
> +{
> + if (!phy)
> + return 0;
> +
> + return -ENOSYS;
> +}
> +
> static inline int phy_get_bus_width(struct phy *phy)
> {
> return -ENOSYS;
--
Kind regar,
Sakari Ailus
Powered by blists - more mailing lists