On Thu, Apr 05, 2018 at 02:09:47PM +0000, Laurentiu Tudor wrote: > Hi Greg, > > On 04/05/2018 03:30 PM, gregkh wrote: > > On Thu, Apr 05, 2018 at 10:30:01AM +0000, Laurentiu Tudor wrote: > >> Hello, > >> > >> My 2c below. > >> > >> On 04/04/2018 03:42 PM, Andrew Lunn wrote: > >>>> I hear you. It is more complicated this way...having all these > >>>> individual > >>>> objects vs just a single "bundle" of them that represents a NIC. But, > >>>> that's > >>>> the way the DPAA2 hardware is, and we're implementing kernel support for > >>>> the hardware as it is. > >>> > >>> Hi Stuart > >>> > >>> I see we are not making any progress here. > >>> > >>> So what i suggest is you post the kernel code and configuration tool > >>> concept to netdev for a full review. You want reviews from David > >>> Miller, Jiri Pirko, Jakub Kicinski, David Ahern, etc. > >>> > >> > >> I think that the discussion steered too much towards networking related > >> topics, while this ioctl doesn't have much to do with networking. > >> It's just an ioctl for our mc-bus bus driver that is used to manage the > >> devices on this bus through userspace tools. > >> In addition, I'd drop any mention of our reference user space app > >> (restool) to emphasize that this ioctl is not added just for a > >> particular user space app. I think Stuart also mentioned this. > > > > I'm not going to take a "generic device configuration ioctl" patch > > unless it is documented to all exactly what it does, and why it is > > there. > > The ioctl() is just a simple pass-through interface to the firmware.
Ah, so a new syscall? :) > It passes commands to the firmware and returns the response back to the > userspace. Thus the ABI used by the firmware applies for this ioctl() > and it is documented in detail here: > > https://www.nxp.com/docs/en/user-guide/DPAA2_UM.pdf Let's wait on this until people all agree that it's ok to expose this directly. thanks, greg k-h
