linux-kernel - Re: [PATCH v4 2/3] PCI: rockchip: Simplify reset control handling by using reset_control

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] [day] [month] [year] [list]

Message-ID: <CANAwSgQiXW3BTxpgLbL__nMQSt90cRbHR849_TqiesfpagiKVQ@mail.gmail.com>
Date: Sun, 25 Aug 2024 15:52:25 +0530
From: Anand Moon <linux.amoon@...il.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Shawn Lin <shawn.lin@...k-chips.com>, Lorenzo Pieralisi <lpieralisi@...nel.org>, 
	Krzysztof Wilczyński <kw@...ux.com>, 
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, Heiko Stuebner <heiko@...ech.de>, 
	Philipp Zabel <p.zabel@...gutronix.de>, linux-pci@...r.kernel.org, 
	linux-rockchip@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/3] PCI: rockchip: Simplify reset control handling by
 using reset_control_bulk*() function

Hi Manivannan

On Wed, 21 Aug 2024 at 12:35, Manivannan Sadhasivam
<manivannan.sadhasivam@...aro.org> wrote:
>
> On Sat, Aug 17, 2024 at 06:52:47PM +0530, Anand Moon wrote:
> > Hi Manivannan,
> >
> > On Thu, 15 Aug 2024 at 21:50, Manivannan Sadhasivam
> > <manivannan.sadhasivam@...aro.org> wrote:
> > >
Trim the message.
> > > >
> > > > @@ -259,31 +184,15 @@ int rockchip_pcie_init_port(struct rockchip_pcie *rockchip)
> > > >        * Please don't reorder the deassert sequence of the following
> > > >        * four reset pins.
> > > >        */
> > >
> > > The comment above says that the resets should not be reordered. But you have
> > > reordered the resets.
> > >
> > As per the TRM [1], CRU_SOFTRST_CON8  clock reset unit has two groups
> > one with reset value 0x1 and the other 0x0, so this patch groups them
> > accordingly.
> >
> > [1] https://opensource.rock-chips.com/images/e/ee/Rockchip_RK3399TRM_V1.4_Part1-20170408.pdf
> >
> > If I only use reset_control_bulk_assert and
> > reset_control_bulk_deassert for all the reset
> > I get the below reset warning.
> >
>
> I think you misunderstood what I asked for. The comment says that the 4 resets
> (mgmt-sticky, core, mgmt, pipe) should not be reordered. In your new group
> rockchip_pci_core_rsts(), you have reordered them. I was just asking you to keep
> the 4 resets sorted as per the comment.
>
Ok, I understood thanks.

Actually as per TRM [1]
17.5.2.2.2 System Reset
The PCIe has the following distinct reset, all of these are
configurable through software
driver. This section describes the function of each of the reset
inputs and the recommended
sequences in which these should be activated. All in all, after power
up, the software driver
should de-assert the reset of PCIe PHY, then wait the PLL locked by
polling the status, if PLL
has locked, then can de-assert the rest reset simultaneously.

[1] https://www.rockchip.fr/Rockchip%20RK3399%20TRM%20V1.3%20Part2.pdf

So I was trying to move all the reset to the common function for the asset
and then call the de-assert once the phy comes up
it is not working at this moment.


[    7.084698] rockchip-pcie f8000000.pcie: no vpcie12v regulator found
[    7.281392] NET: Registered PF_ALG protocol family
[    7.372972] 8021q: 802.1Q VLAN Support v1.8
[    7.830860] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
[    7.831528] rockchip-pcie f8000000.pcie: probe with driver
rockchip-pcie failed with error -110

Meanwhile, I found PCIe GRF from the TRM Part 1 is missing for this so, I
 will add this to this series in the next version, let see if there is
improvement

#define GRF_SOC_CON_5_PCIE     0x0e214
#define GRF_SOC_CON_9_PCIE     0x0e224

> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்

Thanks
-Anand