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  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:   Mon, 27 Jul 2020 22:32:41 +0530
From:   Sekhar Nori <nsekhar@...com>
To:     Vinod Koul <vkoul@...nel.org>
CC:     Swapnil Jakhade <sjakhade@...ence.com>, <kishon@...com>,
        <linux-kernel@...r.kernel.org>, <maxime@...no.tech>,
        <mparab@...ence.com>, <yamonkar@...ence.com>,
        <tomi.valkeinen@...com>, <jsarha@...com>, <praneeth@...com>
Subject: Re: [PATCH v4 0/2] Add new PHY APIs to framework to get/set PHY
 attributes

On 7/27/20 3:25 PM, Vinod Koul wrote:
> Hi Sekhar,
> 
> On 26-07-20, 01:24, Sekhar Nori wrote:
>> Hi Vinod,
>>
>> On 7/17/20 12:20 PM, Swapnil Jakhade wrote:
>>> This patch series adds a new pair of PHY APIs that can be used to get/set
>>> all the PHY attributes. It also adds a new PHY attribute max_link_rate.
>>>
>>> It includes following patches:
>>>
>>> 1. v4-0001-phy-Add-new-PHY-attribute-max_link_rate-and-APIs-.patch
>>> This patch adds max_link_rate as a new PHY attribute along with a pair of
>>> APIs that allow using the generic PHY subsystem to get/set PHY attributes
>>> supported by the PHY.
>>>
>>> 2. v4-0002-phy-cadence-torrent-Use-kernel-PHY-API-to-set-PHY.patch
>>> This patch uses PHY API phy_set_attrs() to set corresponding PHY properties
>>> in Cadence Torrent PHY driver. This will enable drivers using this PHY to
>>> read these properties using PHY framework.
>>>
>>> The phy_get_attrs() API will be used in the DRM bridge driver [1] which is
>>> in the process of upstreaming.
>>
>> Is it possible to queue these for v5.9 also? I did notice that phy
>> updates for v5.9-rc1 are posted already. But these APIs are needed for
>> the DisplayPort driver thats getting ready for merge too. Having these
>> queued now will make managing dependencies much easier.
> 
> I would prefer if we defer core change to post rc1. For your display, we
> can provide a signed tag for you/drm folks to fetch.
> 
> Would that be okay?

Okay, that would work too.

Thanks,
Sekhar

Powered by blists - more mailing lists