On Tue, Jan 18, 2022 at 07:50:34AM -0600, Nishanth Menon wrote: > 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..
Non-linux bindings still go upstream. This is probably also a good reminder go poke Rob about the current U-Boot bindings that're otherwise waiting for merge or further comment. dts files are still a follow-up discussion to have, but bindings I believe has been settled and agreed on. -- Tom
signature.asc
Description: PGP signature