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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 6 Oct 2021 00:33:25 +0200
From:   Mauro Carvalho Chehab <>
To:     Pali Rohár <>
Cc:     Bjorn Helgaas <>,,,
        Krzysztof Wilczyński <>,
        Binghui Wang <>,
        Lorenzo Pieralisi <>,
        Rob Herring <>,
        Xiaowei Song <>,,
Subject: Re: [PATCH v12 03/11] PCI: kirin: Add support for a PHY layer

Hi Pali,

Em Tue, 5 Oct 2021 22:31:48 +0200
Pali Rohár <> escreveu:

> Hello!
> On Tuesday 28 September 2021 09:34:13 Mauro Carvalho Chehab wrote:
> > The pcie-kirin driver contains both PHY and generic PCI driver
> > on it.
> > 
> > The best would be, instead, to support a PCI PHY driver, making
> > the driver more generic.
> > 
> > However, it is too late to remove the Kirin 960 PHY, as a change
> > like that would make the DT schema incompatible with past versions.  
> I have not looked deeply at it. But is not it really possible to declare
> PHY node in DTS file with backward compatible manner? Or cannot Rob help
> with it (maybe there was similar issue in past with other driver)?

It would be possible to split the Kirin 960 PHY into drivers/phy. It is
also possible to hack the phy driver to search for the PHY-specific data
inside the PCI compatible string (I did wrote some patches doing that
and sent as a RFC several months ago), but the problem is that the
PHY driver won't be probed without adding a new compatible inside the
DT schema. By doing that, the schema will be incompatible.

In any case, the patches on this series split all PHY-specific code
inside the driver on a separate part of the source code. Moving it
to a new driver would be easy once someone comes with a solution
to add some new method at the PHY layer that would allow to load a
new module without having a compatible for it.

> I was fixing something similar, address space defined in DTS was used by
> two HW blocks: clock and UART. And I was able to make both DTS file and
> driver backward compatible.


Powered by blists - more mailing lists