On Fri, May 23, 2025 at 09:54:47AM -0500, Nishanth Menon wrote: > On 08:09-20250523, Tom Rini wrote: > > On Fri, May 23, 2025 at 06:54:00AM -0500, Nishanth Menon wrote: > > > On 12:05-20250523, Beleswar Prasad Padhi wrote: > > > > Hi Nishanth, > > > > > > > > On 5/22/2025 9:18 PM, Nishanth Menon wrote: > > > > > On 08:45-20250522, Tom Rini wrote: > > > > > > On Thu, May 22, 2025 at 12:48:28PM +0530, Beleswar Padhi wrote: > > > > > > > > > > > > > Previously, MCU R5F runs in lockstep mode. Enable split-mode on > > > > > > > MCU R5F > > > > > > > as the support to shut down core1 and use it for loading other > > > > > > > firmware, > > > > > > > while DM runs on core0, has been added. > > > > > > > > > > > > > > Signed-off-by: Beleswar Padhi <b-pa...@ti.com> > > > > > > > --- > > > > > > > dts/upstream/src/arm64/ti/k3-j7200-mcu-wakeup.dtsi > > > > > > > | 2 +- > > > > > > > dts/upstream/src/arm64/ti/k3-j721e-mcu-wakeup.dtsi > > > > > > > | 2 +- > > > > > > > dts/upstream/src/arm64/ti/k3-j721s2-mcu-wakeup.dtsi > > > > > > > | 2 +- > > > > > > > .../src/arm64/ti/k3-j784s4-j742s2-mcu-wakeup-common.dtsi > > > > > > > | 2 +- > > > > > > > 4 files changed, 4 insertions(+), 4 deletions(-) > > > > > > Please don't post DONOTMERGE patches. If the series can be applied > > > > > > without this patch, because the functionality is backwards > > > > > > compatible > > > > > > put these changes in the cover letter or link to a gist or similar > > > > > > to > > > > > > show how to test the changes locally. If the series can't be merged > > > > > > until the DTS changes are ready too, please mark the whole thing as > > > > > > RFC. > > > > > > For clarity, what is the case with this series? > > > > > While I appreciate the energy to get upstream, > > > > > > > > > > > > Thanks :) > > > > > > > > > <vent> > > > > > I think this habit of jumping ahead of kernel should be > > > > > stopped. > > > > > https://lore.kernel.org/all/20250522073426.329344-1-b-pa...@ti.com/ > > > > > was > > > > > posted, but not reviewed or accepted. I understand that there is a > > > > > latency in picking things up in upstream kernel, but creating churn is > > > > > not the right way of doing things. It took us an year+ to get > > > > > OF_UPSTREAM settled down. At least wait for kernel maintainers to > > > > > queue > > > > > things up before attempting to sync u-boot with non-mainlined patches. > > > > > </vent> > > > > > > > > > > > > Actually the functionality added in this series is independent of the DT > > > > patch. I posted this DT patch here as DONOTMERGE just so that folks can > > > > know > > > > how to test the functionality. > > > > > > > > I understand your concern, and if it was the case that these changes > > > > were > > > > dependent on the DT, I would have waited until the DT patch is picked up > > > > before posting this series here. > > > > > > use gist next time if your intent is to show how to test it.. Let us > > > continue the discussion on the kernel list for the dts portion > > > > So it sounds like the bindings being used here aren't settled then? I'm > > going to mark the whole series as RFC for now then, if so. > > No change in bindings. Just the approach in this "easy to reproduce" > patch does the change on SoC dtsi. I dont think that was the author's > intent (and yes, i was confused as well). The question in kernel at > least is organizing this in the right board dts/overlay methodology. > > Question then is: do we wait for kernel dts to settle down OR do we get > the u-boot infra for handling these combinations ahead of the changes > (more or less like do we do the driver fixes first or dts fixes first? > in kernel at least, we do the driver fixes first)..
As the author said there's no functional regressions / etc with the rest of the series, yes, I can pickup 1-5 for -next in due time, assuming no feedback on the changes themselves. -- Tom
signature.asc
Description: PGP signature
