linux-kernel - Re: [PATCH v1 2/2] phy: phy-cadence-torrent: Use PHY kernel APIs to set PHY attributes

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, 13 May 2020 08:07:32 +0530
From:   Kishon Vijay Abraham I <kishon@...com>
To:     Tomi Valkeinen <tomi.valkeinen@...com>,
        Maxime Ripard <maxime@...no.tech>,
        Swapnil Kashinath Jakhade <sjakhade@...ence.com>
CC:     Yuti Suresh Amonkar <yamonkar@...ence.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "jsarha@...com" <jsarha@...com>,
        "praneeth@...com" <praneeth@...com>,
        Milind Parab <mparab@...ence.com>,
        Vinod Koul <vkoul@...nel.org>
Subject: Re: [PATCH v1 2/2] phy: phy-cadence-torrent: Use PHY kernel APIs to
 set PHY attributes

Hi,

On 5/8/2020 1:20 PM, Tomi Valkeinen wrote:
> On 07/05/2020 20:17, Maxime Ripard wrote:
> 
>>> Actually, for this particular case, consumer driver will be the Cadence MHDP
>>> bridge driver for DisplayPort which is also under review process for
>>> upstreaming [1]. So this DRM bridge driver will make use of the PHY APIs
>>> phy_get_bus_width() and phy_get_max_link_rate() during execution of probe
>>> function to get the number of lanes and maximum link rate supported by Cadence
>>> Torrent PHY. This information is required to set the host capabilities in the
>>> DRM bridge driver, based on which initial values for DisplayPort link training
>>> will be determined.
>>>
>>> The changes in this PHY patch series are based on suggestions in the review
>>> comments in [1] which asks to use kernel PHY APIs to read these properties
>>> instead of directly accessing PHY device node. The complete driver and actual
>>> use of these APIs can be found in [2]. This is how we are planning to use
>>> these APIs.
>>
>> I haven't really looked into the displayport spec, but I'd assume that there's a
>> lot more parameters that would need to be negociated between the phy and the DP
>> block? If so, then it would make more sense to follow the path we did for
>> MIPI-DSI where the parameters can be negociated through the phy_configure /
>> phy_validate interface.
> 
> I don't think this is negotiation, but just exposing the (max) capabilities of
> PHY, inside which the configure can work. Maybe all the capabilities could
> handled with a struct (struct phy_attrs), instead of adding separate functions
> for each, though.

yeah, that makes sense. Just that users should take care not to over-write all
the phy attributes with partial information.

Thanks
Kishon