RE: [PATCH V7 00/11] misc: xilinx sd-fec drive
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Wednesday 31 July 2019 13:49 > To: Dragan Cvetic > Cc: a...@arndb.de; Michal Simek ; > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > mark.rutl...@arm.com; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; Derek Kiernan > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive > > On Sat, Jun 22, 2019 at 05:54:04PM +, Dragan Cvetic wrote: > > > > > > > -Original Message- > > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > > Sent: Saturday 22 June 2019 07:02 > > > To: Dragan Cvetic > > > Cc: a...@arndb.de; Michal Simek ; > > > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > > > mark.rutl...@arm.com; devicet...@vger.kernel.org; > > > linux-kernel@vger.kernel.org; Derek Kiernan > > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive > > > > > > On Fri, Jun 21, 2019 at 05:49:45PM +, Dragan Cvetic wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > > > > Sent: Friday 21 June 2019 15:16 > > > > > To: Dragan Cvetic > > > > > Cc: a...@arndb.de; Michal Simek ; > > > > > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > > > > > mark.rutl...@arm.com; devicet...@vger.kernel.org; > > > > > linux-kernel@vger.kernel.org; Derek Kiernan > > > > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive > > > > > > > > > > On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote: > > > > > > This patchset is adding the full Soft Decision Forward Error > > > > > > Correction (SD-FEC) driver implementation, driver DT binding and > > > > > > driver documentation. > > > > > > > > > > > > Forward Error Correction (FEC) codes such as Low Density Parity > > > > > > Check (LDPC) and turbo codes provide a means to control errors in > > > > > > data transmissions over unreliable or noisy communication > > > > > > channels. The SD-FEC Integrated Block is an optimized block for > > > > > > soft-decision decoding of these codes. Fixed turbo codes are > > > > > > supported directly, whereas custom and standardized LDPC codes > > > > > > are supported through the ability to specify the parity check > > > > > > matrix through an AXI4-Lite bus or using the optional programmable > > > > > > (PL)-based support logic. For the further information see > > > > > > https://www.xilinx.com/support/documentation/ip_documentation/ > > > > > > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf > > > > > > > > > > > > This driver is a platform device driver which supports SDFEC16 > > > > > > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and > > > > > > Turbo code decoding. LDPC codes can be specified on > > > > > > a codeword-by-codeword basis, also a custom LDPC code can be used. > > > > > > > > > > > > The SD-FEC driver exposes a char device interface and supports > > > > > > file operations: open(), close(), poll() and ioctl(). The driver > > > > > > allows only one usage of the device, open() limits the number of > > > > > > driver instances. The driver also utilize Common Clock Framework > > > > > > (CCF). > > > > > > > > > > > > The control and monitoring is supported over ioctl system call. > > > > > > The features supported by ioctl(): > > > > > > - enable or disable data pipes to/from device > > > > > > - configure the FEC algorithm parameters > > > > > > - set the order of data > > > > > > - provide a control of a SDFEC bypass option > > > > > > - activates/deactivates SD-FEC > > > > > > - collect and provide statistical data > > > > > > - enable/disable interrupt mode > > > > > > > > > > Is there any userspace tool that talks to this device using these > > > > > custom > > > > > ioctls yet? > > > > > > > > > Tools no, but could be the customer who is using the driver. > > > > > > I don't understand
Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
On Sat, Jun 22, 2019 at 05:54:04PM +, Dragan Cvetic wrote: > > > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Saturday 22 June 2019 07:02 > > To: Dragan Cvetic > > Cc: a...@arndb.de; Michal Simek ; > > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > > mark.rutl...@arm.com; devicet...@vger.kernel.org; > > linux-kernel@vger.kernel.org; Derek Kiernan > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive > > > > On Fri, Jun 21, 2019 at 05:49:45PM +, Dragan Cvetic wrote: > > > > > > > > > > -Original Message- > > > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > > > Sent: Friday 21 June 2019 15:16 > > > > To: Dragan Cvetic > > > > Cc: a...@arndb.de; Michal Simek ; > > > > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > > > > mark.rutl...@arm.com; devicet...@vger.kernel.org; > > > > linux-kernel@vger.kernel.org; Derek Kiernan > > > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive > > > > > > > > On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote: > > > > > This patchset is adding the full Soft Decision Forward Error > > > > > Correction (SD-FEC) driver implementation, driver DT binding and > > > > > driver documentation. > > > > > > > > > > Forward Error Correction (FEC) codes such as Low Density Parity > > > > > Check (LDPC) and turbo codes provide a means to control errors in > > > > > data transmissions over unreliable or noisy communication > > > > > channels. The SD-FEC Integrated Block is an optimized block for > > > > > soft-decision decoding of these codes. Fixed turbo codes are > > > > > supported directly, whereas custom and standardized LDPC codes > > > > > are supported through the ability to specify the parity check > > > > > matrix through an AXI4-Lite bus or using the optional programmable > > > > > (PL)-based support logic. For the further information see > > > > > https://www.xilinx.com/support/documentation/ip_documentation/ > > > > > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf > > > > > > > > > > This driver is a platform device driver which supports SDFEC16 > > > > > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and > > > > > Turbo code decoding. LDPC codes can be specified on > > > > > a codeword-by-codeword basis, also a custom LDPC code can be used. > > > > > > > > > > The SD-FEC driver exposes a char device interface and supports > > > > > file operations: open(), close(), poll() and ioctl(). The driver > > > > > allows only one usage of the device, open() limits the number of > > > > > driver instances. The driver also utilize Common Clock Framework > > > > > (CCF). > > > > > > > > > > The control and monitoring is supported over ioctl system call. > > > > > The features supported by ioctl(): > > > > > - enable or disable data pipes to/from device > > > > > - configure the FEC algorithm parameters > > > > > - set the order of data > > > > > - provide a control of a SDFEC bypass option > > > > > - activates/deactivates SD-FEC > > > > > - collect and provide statistical data > > > > > - enable/disable interrupt mode > > > > > > > > Is there any userspace tool that talks to this device using these custom > > > > ioctls yet? > > > > > > > Tools no, but could be the customer who is using the driver. > > > > I don't understand this. Who has written code to talk to these > > special ioctls from userspace? Is there a pointer to that code > > anywhere? > > > > The code which use this driver are written by the driver maintainers > they are examples APP and test code which are not public. So, no open code is talking to this one specific driver? And you have run this past your lawyers? Please go talk to them about this and see what they say (hint, creating a custom ioctl that only you use is a "fun" legal area...) > > > > Doing a one-off ioctl api is always a risky thing, you are pretty much > > > > just creating brand new system calls for one piece of hardware. > > > > > > > > > > Why is that wrong and what is the risk? > > >
RE: [PATCH V7 00/11] misc: xilinx sd-fec drive
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Saturday 22 June 2019 07:02 > To: Dragan Cvetic > Cc: a...@arndb.de; Michal Simek ; > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > mark.rutl...@arm.com; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; Derek Kiernan > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive > > On Fri, Jun 21, 2019 at 05:49:45PM +, Dragan Cvetic wrote: > > > > > > > -Original Message- > > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > > Sent: Friday 21 June 2019 15:16 > > > To: Dragan Cvetic > > > Cc: a...@arndb.de; Michal Simek ; > > > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > > > mark.rutl...@arm.com; devicet...@vger.kernel.org; > > > linux-kernel@vger.kernel.org; Derek Kiernan > > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive > > > > > > On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote: > > > > This patchset is adding the full Soft Decision Forward Error > > > > Correction (SD-FEC) driver implementation, driver DT binding and > > > > driver documentation. > > > > > > > > Forward Error Correction (FEC) codes such as Low Density Parity > > > > Check (LDPC) and turbo codes provide a means to control errors in > > > > data transmissions over unreliable or noisy communication > > > > channels. The SD-FEC Integrated Block is an optimized block for > > > > soft-decision decoding of these codes. Fixed turbo codes are > > > > supported directly, whereas custom and standardized LDPC codes > > > > are supported through the ability to specify the parity check > > > > matrix through an AXI4-Lite bus or using the optional programmable > > > > (PL)-based support logic. For the further information see > > > > https://www.xilinx.com/support/documentation/ip_documentation/ > > > > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf > > > > > > > > This driver is a platform device driver which supports SDFEC16 > > > > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and > > > > Turbo code decoding. LDPC codes can be specified on > > > > a codeword-by-codeword basis, also a custom LDPC code can be used. > > > > > > > > The SD-FEC driver exposes a char device interface and supports > > > > file operations: open(), close(), poll() and ioctl(). The driver > > > > allows only one usage of the device, open() limits the number of > > > > driver instances. The driver also utilize Common Clock Framework > > > > (CCF). > > > > > > > > The control and monitoring is supported over ioctl system call. > > > > The features supported by ioctl(): > > > > - enable or disable data pipes to/from device > > > > - configure the FEC algorithm parameters > > > > - set the order of data > > > > - provide a control of a SDFEC bypass option > > > > - activates/deactivates SD-FEC > > > > - collect and provide statistical data > > > > - enable/disable interrupt mode > > > > > > Is there any userspace tool that talks to this device using these custom > > > ioctls yet? > > > > > Tools no, but could be the customer who is using the driver. > > I don't understand this. Who has written code to talk to these > special ioctls from userspace? Is there a pointer to that code > anywhere? > > > > Doing a one-off ioctl api is always a risky thing, you are pretty much > > > just creating brand new system calls for one piece of hardware. > > > > > > > Why is that wrong and what is the risk? > > You now have custom syscalls for one specfic piece of hardware that you > now have to maintain working properly for the next 40+ years. You have > to make sure those calls are correct and that this is the correct api to > talk to this hardware. > The only idea I have got from the comments are to do more abstraction eg. have a few ioctls with the abstraction done through the passing arguments? > > What would you propose? > > Definitely, I have to read about this. > > What is this hardware and what is it used for? Who will be talking to > it from userspace? What userspace workload uses it? What tools need to > talk to it? Where is the code that uses these new apis? > > thanks, > > greg k-h
RE: [PATCH V7 00/11] misc: xilinx sd-fec drive
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Saturday 22 June 2019 07:02 > To: Dragan Cvetic > Cc: a...@arndb.de; Michal Simek ; > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > mark.rutl...@arm.com; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; Derek Kiernan > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive > > On Fri, Jun 21, 2019 at 05:49:45PM +, Dragan Cvetic wrote: > > > > > > > -Original Message- > > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > > Sent: Friday 21 June 2019 15:16 > > > To: Dragan Cvetic > > > Cc: a...@arndb.de; Michal Simek ; > > > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > > > mark.rutl...@arm.com; devicet...@vger.kernel.org; > > > linux-kernel@vger.kernel.org; Derek Kiernan > > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive > > > > > > On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote: > > > > This patchset is adding the full Soft Decision Forward Error > > > > Correction (SD-FEC) driver implementation, driver DT binding and > > > > driver documentation. > > > > > > > > Forward Error Correction (FEC) codes such as Low Density Parity > > > > Check (LDPC) and turbo codes provide a means to control errors in > > > > data transmissions over unreliable or noisy communication > > > > channels. The SD-FEC Integrated Block is an optimized block for > > > > soft-decision decoding of these codes. Fixed turbo codes are > > > > supported directly, whereas custom and standardized LDPC codes > > > > are supported through the ability to specify the parity check > > > > matrix through an AXI4-Lite bus or using the optional programmable > > > > (PL)-based support logic. For the further information see > > > > https://www.xilinx.com/support/documentation/ip_documentation/ > > > > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf > > > > > > > > This driver is a platform device driver which supports SDFEC16 > > > > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and > > > > Turbo code decoding. LDPC codes can be specified on > > > > a codeword-by-codeword basis, also a custom LDPC code can be used. > > > > > > > > The SD-FEC driver exposes a char device interface and supports > > > > file operations: open(), close(), poll() and ioctl(). The driver > > > > allows only one usage of the device, open() limits the number of > > > > driver instances. The driver also utilize Common Clock Framework > > > > (CCF). > > > > > > > > The control and monitoring is supported over ioctl system call. > > > > The features supported by ioctl(): > > > > - enable or disable data pipes to/from device > > > > - configure the FEC algorithm parameters > > > > - set the order of data > > > > - provide a control of a SDFEC bypass option > > > > - activates/deactivates SD-FEC > > > > - collect and provide statistical data > > > > - enable/disable interrupt mode > > > > > > Is there any userspace tool that talks to this device using these custom > > > ioctls yet? > > > > > Tools no, but could be the customer who is using the driver. > > I don't understand this. Who has written code to talk to these > special ioctls from userspace? Is there a pointer to that code > anywhere? > The code which use this driver are written by the driver maintainers they are examples APP and test code which are not public. > > > Doing a one-off ioctl api is always a risky thing, you are pretty much > > > just creating brand new system calls for one piece of hardware. > > > > > > > Why is that wrong and what is the risk? > > You now have custom syscalls for one specfic piece of hardware that you > now have to maintain working properly for the next 40+ years. You have > to make sure those calls are correct and that this is the correct api to > talk to this hardware. This is very specific HW, it's high speed Forward Error Correction HW. I'll be happy if I maintain this for the next 40+ years. Actually, forgive me asking, what architecture would make me not maintain this driver next 40+ years? > > > What would you propose? > > Definitely, I have to read about this. > > What is this hardware and what is it used for? Who will be talking to The Soft-Decision Forward Error Correction (SD-FEC) integrated block supports Low Density Parity Check (LDPC) decoding and encoding and Turbo code decoding. SD-FEC use case is in high data rate applications such as 4G, 5G and DOCSIS3.1 Cable Access. A high performance SD-FEC (i.e. >1Gbps), is a block used to enable these systems to function under non-ideal environments. > it from userspace? What userspace workload uses it? What tools need to There will be APP which configures the HW for the use cases listed above. Thanks Dragan > talk to it? Where is the code that uses these new apis? > > thanks, > > greg k-h
Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
On Fri, Jun 21, 2019 at 05:49:45PM +, Dragan Cvetic wrote: > > > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Friday 21 June 2019 15:16 > > To: Dragan Cvetic > > Cc: a...@arndb.de; Michal Simek ; > > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > > mark.rutl...@arm.com; devicet...@vger.kernel.org; > > linux-kernel@vger.kernel.org; Derek Kiernan > > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive > > > > On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote: > > > This patchset is adding the full Soft Decision Forward Error > > > Correction (SD-FEC) driver implementation, driver DT binding and > > > driver documentation. > > > > > > Forward Error Correction (FEC) codes such as Low Density Parity > > > Check (LDPC) and turbo codes provide a means to control errors in > > > data transmissions over unreliable or noisy communication > > > channels. The SD-FEC Integrated Block is an optimized block for > > > soft-decision decoding of these codes. Fixed turbo codes are > > > supported directly, whereas custom and standardized LDPC codes > > > are supported through the ability to specify the parity check > > > matrix through an AXI4-Lite bus or using the optional programmable > > > (PL)-based support logic. For the further information see > > > https://www.xilinx.com/support/documentation/ip_documentation/ > > > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf > > > > > > This driver is a platform device driver which supports SDFEC16 > > > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and > > > Turbo code decoding. LDPC codes can be specified on > > > a codeword-by-codeword basis, also a custom LDPC code can be used. > > > > > > The SD-FEC driver exposes a char device interface and supports > > > file operations: open(), close(), poll() and ioctl(). The driver > > > allows only one usage of the device, open() limits the number of > > > driver instances. The driver also utilize Common Clock Framework > > > (CCF). > > > > > > The control and monitoring is supported over ioctl system call. > > > The features supported by ioctl(): > > > - enable or disable data pipes to/from device > > > - configure the FEC algorithm parameters > > > - set the order of data > > > - provide a control of a SDFEC bypass option > > > - activates/deactivates SD-FEC > > > - collect and provide statistical data > > > - enable/disable interrupt mode > > > > Is there any userspace tool that talks to this device using these custom > > ioctls yet? > > > Tools no, but could be the customer who is using the driver. I don't understand this. Who has written code to talk to these special ioctls from userspace? Is there a pointer to that code anywhere? > > Doing a one-off ioctl api is always a risky thing, you are pretty much > > just creating brand new system calls for one piece of hardware. > > > > Why is that wrong and what is the risk? You now have custom syscalls for one specfic piece of hardware that you now have to maintain working properly for the next 40+ years. You have to make sure those calls are correct and that this is the correct api to talk to this hardware. > What would you propose? > Definitely, I have to read about this. What is this hardware and what is it used for? Who will be talking to it from userspace? What userspace workload uses it? What tools need to talk to it? Where is the code that uses these new apis? thanks, greg k-h
RE: [PATCH V7 00/11] misc: xilinx sd-fec drive
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Friday 21 June 2019 15:16 > To: Dragan Cvetic > Cc: a...@arndb.de; Michal Simek ; > linux-arm-ker...@lists.infradead.org; robh...@kernel.org; > mark.rutl...@arm.com; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; Derek Kiernan > Subject: Re: [PATCH V7 00/11] misc: xilinx sd-fec drive > > On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote: > > This patchset is adding the full Soft Decision Forward Error > > Correction (SD-FEC) driver implementation, driver DT binding and > > driver documentation. > > > > Forward Error Correction (FEC) codes such as Low Density Parity > > Check (LDPC) and turbo codes provide a means to control errors in > > data transmissions over unreliable or noisy communication > > channels. The SD-FEC Integrated Block is an optimized block for > > soft-decision decoding of these codes. Fixed turbo codes are > > supported directly, whereas custom and standardized LDPC codes > > are supported through the ability to specify the parity check > > matrix through an AXI4-Lite bus or using the optional programmable > > (PL)-based support logic. For the further information see > > https://www.xilinx.com/support/documentation/ip_documentation/ > > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf > > > > This driver is a platform device driver which supports SDFEC16 > > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and > > Turbo code decoding. LDPC codes can be specified on > > a codeword-by-codeword basis, also a custom LDPC code can be used. > > > > The SD-FEC driver exposes a char device interface and supports > > file operations: open(), close(), poll() and ioctl(). The driver > > allows only one usage of the device, open() limits the number of > > driver instances. The driver also utilize Common Clock Framework > > (CCF). > > > > The control and monitoring is supported over ioctl system call. > > The features supported by ioctl(): > > - enable or disable data pipes to/from device > > - configure the FEC algorithm parameters > > - set the order of data > > - provide a control of a SDFEC bypass option > > - activates/deactivates SD-FEC > > - collect and provide statistical data > > - enable/disable interrupt mode > > Is there any userspace tool that talks to this device using these custom > ioctls yet? > Tools no, but could be the customer who is using the driver. > Doing a one-off ioctl api is always a risky thing, you are pretty much > just creating brand new system calls for one piece of hardware. > Why is that wrong and what is the risk? What would you propose? Definitely, I have to read about this. > Anyway, I took the first 3 patches here because they looked sane. and > stopped when I ran into the ioctl problem... > Thanks for these 3 Dragan > thanks, > > greg k-h
Re: [PATCH V7 00/11] misc: xilinx sd-fec drive
On Tue, Jun 11, 2019 at 06:29:34PM +0100, Dragan Cvetic wrote: > This patchset is adding the full Soft Decision Forward Error > Correction (SD-FEC) driver implementation, driver DT binding and > driver documentation. > > Forward Error Correction (FEC) codes such as Low Density Parity > Check (LDPC) and turbo codes provide a means to control errors in > data transmissions over unreliable or noisy communication > channels. The SD-FEC Integrated Block is an optimized block for > soft-decision decoding of these codes. Fixed turbo codes are > supported directly, whereas custom and standardized LDPC codes > are supported through the ability to specify the parity check > matrix through an AXI4-Lite bus or using the optional programmable > (PL)-based support logic. For the further information see > https://www.xilinx.com/support/documentation/ip_documentation/ > sd_fec/v1_1/pg256-sdfec-integrated-block.pdf > > This driver is a platform device driver which supports SDFEC16 > (16nm) IP. SD-FEC driver supports LDPC decoding and encoding and > Turbo code decoding. LDPC codes can be specified on > a codeword-by-codeword basis, also a custom LDPC code can be used. > > The SD-FEC driver exposes a char device interface and supports > file operations: open(), close(), poll() and ioctl(). The driver > allows only one usage of the device, open() limits the number of > driver instances. The driver also utilize Common Clock Framework > (CCF). > > The control and monitoring is supported over ioctl system call. > The features supported by ioctl(): > - enable or disable data pipes to/from device > - configure the FEC algorithm parameters > - set the order of data > - provide a control of a SDFEC bypass option > - activates/deactivates SD-FEC > - collect and provide statistical data > - enable/disable interrupt mode Is there any userspace tool that talks to this device using these custom ioctls yet? Doing a one-off ioctl api is always a risky thing, you are pretty much just creating brand new system calls for one piece of hardware. Anyway, I took the first 3 patches here because they looked sane. and stopped when I ran into the ioctl problem... thanks, greg k-h
