RE: [PATCH misc v2 2/2] misc: Add Renesas Synchronization Management Unit (SMU) support

[Min Li <min.li.xe@renesas.com>]

> 
> Please put that link in the changelog comment and in the .c code as well so
> that people know where to find it.
> 
> > >
> > > Why is this new api not a standard one?
> > >
> >
> > There is no actual standard for the GNSS assisted partial timing
> > support (APTS) In terms of Linux kernel API
> 
> Then make one!  :)

Yes it is on our roadmap to do that for next release

> 
> > > What is the standard here?
> > >
> > > What do other devices do and why is this a new api?
> > >
> >
> > There is really no standard for APTS and different company has its own
> > hw/sw solutions
> 
> But userspace has to all deal with this in a standard way somehow, right?
> What libraries and apis do they interact with there?

So far there is none. Some companies just use userspace driver and don't bother
kernel

> 
> > > > Current version provides kernel API's to support the following
> > > > functions -set combomode to enable SYNCE clock support -read
> > > > dpll's state to determine if the dpll is locked to the GNSS
> > > > channel -read dpll's ffo (fractional frequency offset) in ppqt
> > >
> > > Why do all of these have to be in the kernel at all?
> > >
> >
> > Because all these API's need spi/i2c accesses to the RSMU card and
> > spi/i2c accesses have been abstracted to the MFD driver in kernel
> 
> Why not just do this all from userspace then?  You can have spi/i2c
> userspace code, right?  Why does this have to be a kernel driver?
> 
We used to do everything in userspace. But since PHC (ptp hardware clock) came along, we decided
to move the driver part to kernel. Please take a look at drivers/ptp/ptp_clockmatrix.c for reference.
Recently, we have some functions like APTS that doesn't belong to PTP or anything else so we have to split those functions
to RSMU misc driver and i2c/spi bus accesses to RSMU MFD driver.