On Fri, Dec 11, 2020 at 01:09:35PM +0100, 'Greg Kroah-Hartman' wrote: > On Fri, Dec 11, 2020 at 09:18:24AM +0000, József Horváth wrote: > > On Fri, Dec 11, 2020 at 09:43:31AM +0100, 'Greg Kroah-Hartman' wrote: > > > On Fri, Dec 11, 2020 at 08:16:34AM +0000, József Horváth wrote: > > > > On Fri, Dec 11, 2020 at 08:33:17AM +0100, 'Greg Kroah-Hartman' wrote: > > > > > On Fri, Dec 11, 2020 at 06:37:52AM +0000, József Horváth wrote: > > > > > > On Fri, Dec 11, 2020 at 07:20:41AM +0100, 'Greg Kroah-Hartman' wrote: > > > > > > > On Fri, Dec 11, 2020 at 06:09:43AM +0000, József Horváth wrote: > > > > > > > > On Fri, Dec 11, 2020 at 06:50:58AM +0100, 'Greg Kroah-Hartman' wrote: > > > > > > > > > On Thu, Dec 10, 2020 at 07:46:25PM +0000, József Horváth wrote: > > > > > > > > > > On Thu, Dec 10, 2020 at 08:03:22PM +0100, 'Greg Kroah-Hartman' wrote: > > > > > > > > > > > On Thu, Dec 10, 2020 at 05:04:46PM +0000, József Horváth wrote: > > > > > > > > > > > > This is a serial port driver for > > > > > > > > > > > > Silicon Labs Si4455 Sub-GHz transciver. > > > > > > > > > > > > + > > > > > > > > > > > > +#define BASE_TTYIOC_PRIVATE 0xA0 > > > > > > > > > > > > +/* Set EZConfig. > > > > > > > > > > > > + * After this ioctl call, the driver restarts the si4455, > > > > > > > > > > > > + * then apply the new configuration and patch. > > > > > > > > > > > > + */ > > > > > > > > > > > > +#define SI4455_IOC_SEZC _IOW('T', \ > > > > > > > > > > > > + BASE_TTYIOC_PRIVATE + 0x01, \ > > > > > > > > > > > > + struct si4455_iocbuff) > > > > > > > > > > > > > > > > > > > > > > Why does a serial driver have private ioctls? Please no, don't do that. > > > > > > > > > > > > > > > > > > > > I checked the ioctl.h and serial_core.h, but I not found any similar definition, like BASE_VIDIOC_PRIVATE in videodev2.h. > > > > > > > > > > In this case the name of macro BASE_TTYIOC_PRIVATE means the base value of special ioctl commands owned by this driver. > > > > > > > > > > > > > > > > > > My point is, a serial driver should NOT have any custom ioctls. > > > > > > > > > > > > > > > > > > > I can change it to BASE_TTYIOC or SI4455_IOC_BASE > > > > > > > > > > > > > > > > > > > > > Implement the basic serial driver first, and then we can talk about > > > > > > > > > > > "custom" configurations and the like, using the correct apis. > > > > > > > > > > > > > > > > > > > > Without the SI4455_IOC_SEZC call, the driver can't configure the Si4455 and not working at all. > > > > > > > > > > The cofiguration for interface is provided by user for application. > > > > > > > > > > > > > > > > > > That is what a device tree is for, to configure the device to have the > > > > > > > > > correct system configuration, why can't that be the same here? > > > > > > > > > > > > > > > > > > > It contains the base frequency, channel spacing, modulation, and a lot > > > > > > > > > > of more stuff, and generated by Silicon Labs Wireless Development > > > > > > > > > > Suite. > > > > > > > > > > The generated configuration is in a non public(compressed, > > > > > > > > > > encrypted...who knows) format, so without this the driver can't > > > > > > > > > > provide configuration parameters to Si4455. > > > > > > > > > > > > > > > > > > So we have to take a "custom" userspace blob and send it to the device > > > > > > > > > to configure it properly? Like Jiri said, sounds like firmware, so just > > > > > > > > > use that interface instead. > > > > > > > > > > > > > > > > I checked Jiri's suggestion, and it is a good solution to replace SI4455_IOC_SEZC(configuration) and SI4455_IOC_SEZP(firmware patch). > > > > > > > > I can move SI4455_IOC_SSIZ(package size) to device tree property. > > > > > > > > > > > > > > > > Maybe you have good suggestion for the following: > > > > > > > > SI4455_IOC_STXC -> Radio transmit channel index. It is a real use case to control this parameter by user at runtime. > > > > > > > > SI4455_IOC_SRXC -> Radio receive channel index. It is a real use case to control this parameter by user at runtime. > > > > > > > > > > > > > > These are not serial port things, why would a serial port care about > > > > > > > these? > > > > > > > > > > > > You are right, these are not regular serial port things, but this device is not a regular uart, it is a sub-GHz transciever, digital radio. > > > > > > This driver tries to represent it as a serial port to user. > > > > > > > > > > Is that the correct representation to be using here? Why not act like a > > > > > proper radio device instead? That way you get to use the normal kernel > > > > > apis for radio devices. > > > > > > > > In my mind it is absolute a serial device by the application. > > > > > > What is the application? Traditionally serial ports don't need radio signals :) > > > > The application is connecting newly developed sensors(with only rf interface) and legacy sensors(with regular serial communication over rs-485 with modbus) keeping the legacy user software. > > > > User sw [Java] > > <-> /dev/ttyXXX > > <-> si4455[driver] > > <-> si4455[hardware] > > <---air---> new device[si4455+ARM Cortex-M0] 1 > > +-> new device[si4455+ARM Cortex-M0] 2 > > +-> new device[si4455+ARM Cortex-M0] n > > +-> gateway[si4455+ARM Cortex-M0]<---RS485--> Legacy device 1 > > +-> Legacy device 2 > > +-> Legacy device n > > If these are "sensors", why are you using a tty interface at all, and > not just using the correct iio interface for them? In this context "legacy sensor" means modbus protocol device over serial/rs485 interface, and "new sensors" means modbus protocol device over air(rf). All kind of devices are 50-100 m away from central(where linux using this serial driver). The goal is to remove the wire between central(linux) and any kind of devices, but keeping the original user software. > > thanks, > > greg k-h Üdvözlettel / Best regards: József Horváth