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]
Date:   Wed, 17 Jul 2019 06:36:09 +0000
From:   "Zengtao (B)" <prime.zeng@...ilicon.com>
To:     Maxime Ripard <maxime.ripard@...tlin.com>
CC:     "kishon@...com" <kishon@...com>, Chen-Yu Tsai <wens@...e.org>,
        "Paul Kocialkowski" <paul.kocialkowski@...tlin.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH] phy: Change the configuration interface param to void*
 to make it more general

Hi Maxime:

Thanks for your reply.

>-----Original Message-----
>From: Maxime Ripard [mailto:maxime.ripard@...tlin.com]
>Sent: Thursday, July 11, 2019 7:21 PM
>To: Zengtao (B) <prime.zeng@...ilicon.com>
>Cc: kishon@...com; Chen-Yu Tsai <wens@...e.org>; Paul Kocialkowski
><paul.kocialkowski@...tlin.com>; Sakari Ailus <sakari.ailus@...ux.intel.com>;
>linux-kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org
>Subject: Re: [PATCH] phy: Change the configuration interface param to void*
>to make it more general
>
>* PGP Signed by an unknown key
>
>On Fri, Jul 12, 2019 at 02:04:08AM +0800, Zeng Tao wrote:
>> The phy framework now allows runtime configurations, but only limited
>> to mipi now, and it's not reasonable to introduce user specified
>> configurations into the union phy_configure_opts structure. An simple
>> way is to replace with a void *.
>
>I'm not sure why it's unreasonable?
>
The phy.h will need to include vendor specific phy headers, and the union phy_configure_opts
will become more complex. I don't think this is a good solution to include all vendor specific phy
configs into a single union structure. 

>> We have already got some phy drivers which introduce private phy API
>> for runtime configurations, and with this patch, they can switch to
>> the phy_configure as a replace.
>
>If you have a custom mode of operation, then you'll need a custom
>phy_mode as well, and surely you can have a custom set of parameters.
>
>Since those functions are meant to provide a two-way negotiation of the
>various parameters, you'll have to have that structure shared between the
>two either way, so the only thing required in addition to what you would have
>passing a void is one line to add that structure in the union.
>
>That's barely unreasonable.
>
>Maxime
>
>--
>Maxime Ripard, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com
>
>* Unknown Key
>* 0x671851C5

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ