>
> Then you need to mention that in the change log.
>
> What changed from v1 => v2?
>
Please see my latest [PATCH next v2] and it has the following change log
Signed-off-by: Min Li
---
-rebase change to linux-next tree
-add log to inform driver loading success
>
> Then you need to mention that in the change log.
>
> What changed from v1 => v2?
>
Please look it up by the latest patch I sent over yesterday. It is under the
Signed-off-by
---
-rebase change to linux-next tree
-add log to inform driver loading success
Hi Lee
I just withdraw the misc driver review and sent you a new patch for mfd change
alone.
I will focus on mfd for now. Please take a look. Thanks
Min
>
> Please provide some sort of documentation and at the least, a pointer to the
> software that uses this so that we can see how it all ties together.
>
Hi Greg, I will withdraw this review for misc and focus on MFD part review for
now. I will re-submit the misc review after mfd change is in.
>
> But what does that have to do with the misc device?
>
Hi Greg, MFD driver is the start of everything. Once MFD driver is loading, it
will spawn 2 devices,
one is for phc driver, which is under /driver/ptp and the other one is for this
misc driver.
Both PHC and misc drivers are operatin
>
> That does not make sense, this is only one kernel module, with one .h file in
> this patch, I do not see those other files you are talking about...
>
> And if you have named registers that are identical, and yet you only work on
> one device, that feels like a design flaw somewhere :)
>
Hi
>
> If this is v3, there should be a changelog here.
>
Hi Lee
There is no change in v3 for MFD part of code, v3 is only for misc part.
But I have to format 2 patches together and that is why mfd part got v3 as well.
But it is actually identical to v2
>
> Why?
>
Because I need to manipulate name by adding the index to it during run time and
use it as miscdev's name
snprintf(rsmu->name, sizeof(rsmu->name), "rsmu%d", rsmu->index);
rsmu->miscdev.name = rsmu->name;
>
> Then why are you saving it off?
>
For things like dev_er
>
> Again, please make this only one file.
>
Hi Greg, the 2 boards have some same named registers in idt82p33_reg.h and
idt8a340_reg.h
so if I put them all in the same file, there will be name conflicts.
>
> Why not use the miscdev name field?
>
miscdev name field is just a char pointer and I need an static array to
manipulate the name with index
>
> So it's a parent? Why not make this a real platform_device pointer and not
> a device pointer?
>
It is not parent and mfd field is the parent
>
> Do you really meen "+" here? (sorry, have to ask.)
>
I don't know. All of our Linux kernel code has GPL-2.0+ and I just blindly
inherit it.
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> You should not need this as it's a driver, so you should only use the
> dev_dbg() family of pri
>
> If you do nothing in an open/release function, then there is no need to have
> them at all, you can remove them.
>
> But this feels odd, how do you know what device you are using in your ioctl
> command?
>
The type of board is passed by mfd driver through platform data
rsmu->type = pdata->
>
> Why do you need 4 files here? Can't you do this all in one? There's no need
> for such a small driver to be split up, that just causes added complexity and
> makes things harder to review and understand.
>
We will add more functions and boards down the road. So the abstraction here is
for
> > >
> > > Any specific reason you are not using the misc_device api? That
> > > would clean up this driver a lot, there's no need to create a whole
> > > class just for a single driver.
> > >
> >
> > Hi Greg
> >
> > No specific reason. I just didn't know the existence of misc_register API.
>
>
>
> Any specific reason you are not using the misc_device api? That would clean
> up this driver a lot, there's no need to create a whole class just for a
> single
> driver.
>
Hi Greg
No specific reason. I just didn't know the existence of misc_register API.
Do you recommend using this API t
>
> Then the patches are independant and they should be sent as such,
> otherwise it causes confusion and our tools get messed up when trying to
> grab the whole "series" of patches.
>
> Can you please fix this up and just send two independant patches?
>
Hi Greg
These 2 patches are not indep
>
> Where is patch 1/2 of this series?
>
> Also, please fix up the errors that the testing bot found, and properly
> version
> your patch submission so I know which one is the "latest" one to look at.
>
Hi Greg
The first patch is mfd so I was not sure if I should send that to you guys in
the
> >
> > I am wondering if this is the correct tree to submit the patch for MFD?
> >
> > So to sum it up, the latest patch is my first version to this tree.
>
> Either MFD or -next is fine for MFD-only patches.
>
> Has the code changed at all in any of the patches?
>
> If so, please provide a cha
>
> I'm pretty confused. This has been sent ~6 times already. What is the v1 of?
> Is this a different driver? If so, why does it have the same $SUBJECT line?
>
> If this is not actually v1. Please provide a change-log.
>
Hi Lee
Sorry for confusion. This is no version before v1. The reaso
Hi Greg
You are right, this is not for the network tree.
Can you point me to the right tree to base this change for?
Thanks
Min
> -Original Message-
> From: Greg KH
> Sent: March 17, 2021 3:20 PM
> To: Min Li
> Cc: derek.kier...@xilinx.com; dragan.cve...@xilinx.com
ase do not hesitate to
get back to me for this issue.
Thanks
Min
> -Original Message-
> From: Arnd Bergmann
> Sent: February 18, 2021 5:51 AM
> To: Min Li
> Cc: Derek Kiernan ; Dragan Cvetic
> ; Arnd Bergmann ; gregkh
> ; linux-kernel@vger.kernel.org; Networking
Hi Lee
When you have time, can you please take a look at my review below?
Thanks
Min
> -Original Message-
> From: min.li...@renesas.com
> Sent: February 10, 2021 10:00 PM
> To: lee.jo...@linaro.org
> Cc: linux-kernel@vger.kernel.org; Min Li
> Subject: [PATCH
-Original Message-
From: Min Li
Sent: February 18, 2021 11:14 AM
To: 'Arnd Bergmann'
Cc: Derek Kiernan ; Dragan Cvetic
; Arnd Bergmann ; gregkh
; linux-kernel@vger.kernel.org; Networking
; Richard Cochran
Subject: RE: [PATCH net-next] misc: Add Renesas Synchronization
> -Original Message-
> From: Arnd Bergmann
> Sent: February 18, 2021 5:51 AM
> To: Min Li
> Cc: Derek Kiernan ; Dragan Cvetic
> ; Arnd Bergmann ; gregkh
> ; linux-kernel@vger.kernel.org; Networking
> ; Richard Cochran
> Subject: Re: [PATCH net-next] misc:
> -Original Message-
> From: Arnd Bergmann
> Sent: February 17, 2021 4:30 PM
> To: Min Li
> Cc: Derek Kiernan ; Dragan Cvetic
> ; Arnd Bergmann ; gregkh
> ; linux-kernel@vger.kernel.org; Networking
> ; Richard Cochran
> Subject: Re: [PATCH net-next] misc:
>
> I can't help but think you are evading my question I asked. If there is no
> specific action that this pcm4l tool needs to perform, then I'd think we
> should better not provide any interface for it at all.
>
> I also found a reference to only closed source software at
> https://www.renesas.c
line manually by
myself when doing "git commit --amend"? git commit will
always add a "---" marker line before the actual change like below
Signed-off-by: Min Li
---
Changes since v1:
-Provide more background for purpose of the change.
-Provide compat_ioctl support
-Fix ioctl cmd definition
---
drivers/misc/Kconfig | 13 ++
drivers/misc/Makefile | 3 +
> >
> > If I come up with a new file and move all the abstraction code there,
> > does that work?
>
> I think so, but it's more important to figure out a good user space interface
> first. The ioctl interfaces should be written on a higher-level abstraction,
> to
> ensure they can work with any h
>
> On Fri, Feb 12, 2021 at 03:44:52PM +0000, Min Li wrote:
> > > >
> > > > -set combomode
> > > > -get dpll's state
> > > > -get dpll's ffo
> > > >
> > > > This driver must work with Renesas MFD driver to acc
>
> Ah, so if this is for a PTP related driver, it should probably be integrated
> into
> the PTP subsystem rather than being a separate class.
>
I was trying to add these functions to PHC subsystem but was not accepted
because the functions
are specific to Renesas device and there is no place
> >
> > If I come up with an rsmu.rst under Documentation/driver-api, is that
> something you are looking for?
>
> No, all sysfs files need to be documented in Documentation/ABI/
>
> thanks,
>
> greg k-h
Hi Greg
I decided to follow Arnd's suggestion and drop the extra sysfs attributes
declara
>
> xilinx_sdfec.c has:
>
> static int xsdfec_dev_open(struct inode *iptr, struct file *fptr)
> {
> return 0;
> }
>
> Which isn't even needed at all, but it is NOT trying to keep people from
> calling open multiple times.
>
> As for why the above logic does not w
> >
> > -set combomode
> > -get dpll's state
> > -get dpll's ffo
> >
> > This driver must work with Renesas MFD driver to access SMU through
> > I2C/SPI.
> >
> > Changes since v1:
> > -Provide more background for purpose of the change.
> > -Provide compat_ioctl support
> > -Fix ioctl cmd definition
> > +
> > + /* Only one open per device at a time */
> > + if (!atomic_dec_and_test(&rsmu->open_count)) {
> > + atomic_inc(&rsmu->open_count);
> > + return -EBUSY;
>
> This does not do what you think it does, and does not prevent multiple
> applications from talking to your
Hi David/Richard
When you have time, can you take a look at this change? Thanks
Min
-Original Message-
From: min.li...@renesas.com
Sent: August 7, 2020 11:58 AM
To: richardcoch...@gmail.com
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Min Li
Subject: [PATCH net 3/4] ptp
Hi David/Richard
When you have time, can you take a look at this change? Thanks
Min
-Original Message-
From: min.li...@renesas.com
Sent: August 7, 2020 11:58 AM
To: richardcoch...@gmail.com
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Min Li
Subject: [PATCH net 2/4] ptp
Hi David/Richard
When you have time, can you take a look at this change? Thanks
Min
-Original Message-
From: min.li...@renesas.com
Sent: August 7, 2020 11:58 AM
To: richardcoch...@gmail.com
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Min Li
Subject: [PATCH net 4/4] ptp
Hi David/Richard
When you have time, can you take a look at this change? Thanks
Min
-Original Message-
From: min.li...@renesas.com
Sent: August 7, 2020 11:56 AM
To: richardcoch...@gmail.com
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Min Li
Subject: [PATCH net 1/4] ptp
38 matches
Mail list logo
