[PATCH v2 01/20] remoteproc: k3_system_controller: Support optional boot_notification channel

[Nishanth Menon]

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 <nm at 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 <nm at 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