linux-kernel - Re: [PATCH 06/12] ARM: dts: am335x-bone-common: Enable PRU-ICSS interconnect node

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: <20200227213031.GK37466@atomide.com>
Date:   Thu, 27 Feb 2020 13:30:31 -0800
From:   Tony Lindgren <tony@...mide.com>
To:     Suman Anna <s-anna@...com>
Cc:     Roger Quadros <rogerq@...com>, Tero Kristo <t-kristo@...com>,
        linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 06/12] ARM: dts: am335x-bone-common: Enable PRU-ICSS
 interconnect node

* Suman Anna <s-anna@...com> [200227 21:29]:
> On 2/26/20 8:07 PM, Tony Lindgren wrote:
> > * Suman Anna <s-anna@...com> [200227 00:59]:
> >> Hi Tony,
> >>
> >> On 2/26/20 4:39 PM, Tony Lindgren wrote:
> >>> * Tony Lindgren <tony@...mide.com> [200226 22:38]:
> >>>> * Suman Anna <s-anna@...com> [200226 20:35]:
> >>>>> On 2/26/20 12:29 PM, Tony Lindgren wrote:
> >>>>>> * Suman Anna <s-anna@...com> [200225 20:47]:
> >>>>>>> The PRU-ICSS target module node was left in disabled state in the base
> >>>>>>> am33xx-l4.dtsi file. Enable this node on all the AM335x beaglebone
> >>>>>>> boards as they mostly use a AM3358 or a AM3359 SoC which do contain
> >>>>>>> the PRU-ICSS IP.
> >>>>>>
> >>>>>> Just get rid of the top level status = "disabled". The default
> >>>>>> is enabled, and the device is there for sure inside the SoC.
> >>>>>> And then there's no need for pointless status = "okay" tinkering
> >>>>>> in the board specific dts files so no need for this patch.
> >>>>>
> >>>>> The IP is not available on all SoCs, and there are about 40 different
> >>>>> board files atm across AM33xx and AM437x, and am not sure what SoCs they
> >>>>> are actually using.
> >>>>
> >>>> Oh that issue again.. Maybe take a look at patch "[PATCH 2/3] bus: ti-sysc:
> >>>> Detect display subsystem related devices" if you can add runtime
> >>>> detection for the accelerators there similar to what I hadded for omap3.
> >>>> acclerators.
> >>>
> >>> Sorry I meant instead patch "[PATCH 6/7] bus: ti-sysc: Implement SoC
> >>> revision handling".
> >>
> >> OK, looked down that path a bit more and looking through mach-omap2/id.c
> >>  and soc.h, I see some of the part number infrastructure build on top of
> >> DEV_FEATURE bits for some SoCs. The DEVICE_ID registers only have the
> >> generic family and the Silicon Revision number for AM33xx and AM437x and
> >> we currently do not have any infrastructure around exact SoC
> >> identification for AM33xx and AM437x atleast.
> >>
> >> Do you have the bit-field split for the DEV_FEATURE bits somewhere,
> >> because I couldn't find any in either the DM or the TRM. On AM437x,
> >> there is no difference between AM4372 and AM4376 DEV_FEATURE value even
> >> though the former doesn't have the PRUSS. On AM335x, may be bit 0
> >> signifies the presence of PRUSS??
> > 
> > OK not sure how that could be detected. Maybe check the efuses on
> > the newer SoCs?
> 
> OK, latest datasheeet has fixed these values up, and they are no longer
> identical. In anycase, none of the current AM437x board dts files in the
> kernel use AM4372, so atleast for AM4372, I can drop the status=disabled
> even without adding any SoC name support.

OK sounds good to me.

Thanks,

Tony