Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31;
Date:   Wed, 18 Oct 2023 10:50:07 -0500
From:   Nishanth Menon <nm@ti.com>
To:     Neha Malcom Francis <n-francis@ti.com>
CC:     <ssantosh@kernel.org>, <t-konduru@ti.com>,
        <linux-kernel@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>, <u-kumar1@ti.com>,
        "Gunasekaran, Ravi" <r-gunasekaran@ti.com>,
        "Quadros, Roger" <rogerq@ti.com>, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH v3 3/3] soc: ti: k3-socinfo: Revamp driver to accommodate
 different rev structs
Message-ID: <20231018155007.rpoqiptrkqatyja5@satchel>
References: <20231016101608.993921-1-n-francis@ti.com>
 <20231016101608.993921-4-n-francis@ti.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20231016101608.993921-4-n-francis@ti.com>
Precedence: bulk

On 15:46-20231016, Neha Malcom Francis wrote:
> k3-socinfo.c driver assumes silicon revisions for every platform are
> incremental and one-to-one, corresponding to JTAG_ID's variant field:
> 1.0, 2.0 etc. This assumption is wrong for SoCs such as J721E, where the
> variant field to revision mapping is 1.0, 1.1. Further, there are SoCs
> such as AM65x where the sub-variant version requires custom decoding of
> other registers.
> 
> Address this by using conditional handling per JTAG ID that requires an
> exception with J721E as the first example. To facilitate this
> conversion, use macros to identify the JTAG_ID part number and map them
> to predefined string array.
> 
> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
> Co-developed-by: Thejasvi Konduru <t-konduru@ti.com>
> Signed-off-by: Thejasvi Konduru <t-konduru@ti.com>
> ---
> Changes since v2:
> 	- update commit message
> 	- move from double Signed-off-by to Co-developed-by
> 	- make j721e_rev_string_map[] a const char
> 	- drop k3_rev_string_map[] and continue using old
> 	  "variant++" logic for the typical cases
> 	- appropriate error handling with no overrides distinguishing
> 	  between ENODEV and ENOMEM
>  

Thanks to linux-next testing, looks like this created regression in networking.

https://lore.kernel.org/all/20231018140009.1725-1-r-gunasekaran@ti.com/

I will drop this patch for now from my queue. I suggest the following
for the eventual resolution:
a) Do all the prep work in a series of atomic bisectable patches prior to introducing
j721e SR change
b) Please sync with Ravi and netdev maintainers as to how to introduce
the changes
c) also introduce changes (if required) to other SoCs as required.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D