On 07:50-20220118, Tom Rini wrote: > On Tue, Jan 18, 2022 at 11:26:50AM +0530, Aswath Govindraju wrote: > > Hi Tomi, > > > > On 17/01/22 7:24 pm, Tom Rini wrote: > > > On Mon, Jan 17, 2022 at 12:22:52PM +0530, Aswath Govindraju wrote: > > >> Hi Tom, > > >> > > >> On 17/01/22 11:01 am, Aswath Govindraju wrote: > > >>> Hi Tom, > > >>> > > >>> On 13/01/22 7:42 pm, Tom Rini wrote: > > >>>> On Tue, Jan 11, 2022 at 01:25:26PM +0530, Aswath Govindraju wrote: > > >>>> > > >>>>> From: Nishanth Menon <n...@ti.com> > > >>>>> > > >>>>> If there is an optional boot notification channel that an SoC uses > > >>>>> separate from the rx path, use the same. > > >>>>> > > >>>>> Signed-off-by: Nishanth Menon <n...@ti.com> > > >>>>> --- > > >>>>> .../remoteproc/k3-system-controller.txt | 3 +++ > > >>>>> drivers/remoteproc/k3_system_controller.c | 20 > > >>>>> ++++++++++++++++++- > > >>>>> 2 files changed, 22 insertions(+), 1 deletion(-) > > >>>> > > >>>> Binding docs are rst these days, so we should sync with upstream and > > >>>> then this property is already there, right? > > >>>> > > >>> > > >>> I will create a followup patch to convert documentation to rst. Also, > > >>> about the property, mbox-names property is already present but > > >>> "boot_notify" is a newly added channel and not are required property. > > >>> So, this was additionally added. > > >>> > > >> > > >> One more question regarding documentation, should it be changed to rst > > >> or yaml, as this is a device tree binding? > > > > > > I mis-spoke, yeah. It should be yaml and pushed upstream first, then > > > brought back here. > > > > > > > I am sorry, I have one more question. This above documentation file is > > not present in kernel documentation, so I did not understand how can > > this be pushed there first. > > > > Also, as converting to yaml would be a different work. Wouldn't it be > > better to separate that work from this series? > > Sigh, it should have been upstreamed first. So yeah, make the changes > you need here now and then please start pushing it upstream, thanks.
Just catching up, but, this goes back to the same question -> this has no relevance beyond R5. what is our current state of sending non-linux dt pieces to upstream kernel? There wont be a driver for sure, neither will there be a direct user in kernel.. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
