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:   Mon, 27 Jul 2020 15:25:15 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     Sekhar Nori <nsekhar@...com>
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

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?

Thanks
-- 
~Vinod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ