linux-kernel - Re: [PATCH 2/2] arm64: dts: qcom: sa8775p-ride-r3: add new board file

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]

Message-ID: <t7ztnomeyebome2xylbp4jygwzod35bqn3rwj4gnivt5rjl7b7@cuuqafqzecyf>
Date: Fri, 21 Jun 2024 09:54:56 -0500
From: Andrew Halaney <ahalaney@...hat.com>
To: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Cc: Bartosz Golaszewski <brgl@...ev.pl>, 
	Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konrad.dybcio@...aro.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] arm64: dts: qcom: sa8775p-ride-r3: add new board file

On Fri, Jun 21, 2024 at 03:14:13PM GMT, Bartosz Golaszewski wrote:
> On Thu, 20 Jun 2024 at 18:04, Andrew Halaney <ahalaney@...hat.com> wrote:
> >
> > > +
> > > +&mdio {
> > > +     compatible = "snps,dwmac-mdio";
> > > +     #address-cells = <1>;
> > > +     #size-cells = <0>;
> > > +
> > > +     sgmii_phy0: phy@8 {
> > > +             compatible = "ethernet-phy-id31c3.1c33";
> > > +             reg = <0x8>;
> > > +             device_type = "ethernet-phy";
> > > +             interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > +             reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > +             reset-assert-us = <11000>;
> > > +             reset-deassert-us = <70000>;
> >
> > I need to read your other series still wrt "ocsgmii", but any chance you
> > have access to docs indicating the reset timing? I've never had docs for
> > the specific Marvell phy on the prior board or the Aquantia one on the
> > new board...
> >
> 
> I have but they're not public. :(
> 
> > Boot time is something automotive is always concerned over, so I just
> > want to make sure that this timing isn't any longer than it needs to be.
> > Right now it looks the same as the Marvell phy's in the "v2" boards etc
> > and that made me raise my eyebrows.
> >
> 
> That's a good point but what else can we do? This should typically
> execute in its own thread anyway.

I guess all I'm asking is are these timings accurate? Ethernet is often
considered one of the things that needs to be up early (think about
getting the vehicle reverse status off the network for example), so in this case
I meant to consider it part of the "boot time".

If this is actually the recommended values then we're good, just wanting to
make sure we're not reusing the Marvell values (which may or may not be accurate
as I don't have the doc) since they could be larger than necessary, etc!

Dealing with the phys is a long pole in the time to get ethernet up in
my benchmarks in the past, that's why I made this change etc:

    https://lore.kernel.org/netdev/20231127-net-phy-reset-once-v2-1-448e8658779e@redhat.com/

If these reset numbers are accurate then we're all good here, just
confirming since they match the "r2" version which uses the marvell phy
instead of the aquantia phy, and that seemed like a suspicious
coincidence!

Thanks,
Andrew