i2c-dev mismatch with proprietary nvidia driver

i2c-dev mismatch with proprietary nvidia driver

[Sanford Rockowitz]

I'm not sure where to post this bug report on the Linux side, I have 
already posted it at developer.nvida.com.  If there's a more appropriate 
location, please let me know.

At approximately line 41 of nvidia driver file nv-i2c.c, in function 
nv_i2c_algo_master_transfer(), there's an if-test for symbol 
I2C_M_DMA_SAFE.  If the symbol is not defined, a call to the function 
with the bit set fails with error -EINVAL. The file includes 
"linux/i2c.h", so apparently there are versions of I2c.h in which the 
flag is undefined.

At approximately line 262 of i2c-dev driver file i2c-dev.c, in function  
i2cdev_ioctl_wdrw(), this bit is set unconditionally, with the comment 
"memdup_user allocates with GFP_KERNEL, so DMA is ok ". This behavior is 
not the result of the userspace caller setting the flag, the driver sets 
it unconditionally. The result is that calls into i2c-dev using its 
ioctl() interface, as opposed to the read()/write() interface, always 
fail with error EINVAL.

Every version of i2c.h that I have defines I2C_M_DMA_SAFE, so the 
version of the nvidia driver that DKMS builds for me works. However, as 
the developer of ddcutil (https://github.com/rockowitz/ddcutil, 
https://www.ddcutil.com) I receive bug reports of failures with the 
nvidia proprietary driver due to this mismatch, so it is a problem.



I

Re: i2c-dev mismatch with proprietary nvidia driver

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

Hi,

> At approximately line 41 of nvidia driver file nv-i2c.c, in function
> nv_i2c_algo_master_transfer(), there's an if-test for symbol I2C_M_DMA_SAFE.
> If the symbol is not defined, a call to the function with the bit set fails
> with error -EINVAL. The file includes "linux/i2c.h", so apparently there are
> versions of I2c.h in which the flag is undefined.

I2C_M_DMA_SAFE is a hint for controller drivers that the buffer is DMA
capable. It is not something the controller driver needs to support
actively. Bailing out on this flag is wrong. Do I need to mention that
such misconceptions are the super-downside of out-of-tree drivers? (I
know that you are only a user of this driver, so not your fault)

Happy hacking,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: i2c-dev mismatch with proprietary nvidia driver

[Sanford Rockowitz]

On 09/28/2022 03:16 PM, Wolfram Sang wrote:
> Hi,
>
>> At approximately line 41 of nvidia driver file nv-i2c.c, in function
>> nv_i2c_algo_master_transfer(), there's an if-test for symbol I2C_M_DMA_SAFE.
>> If the symbol is not defined, a call to the function with the bit set fails
>> with error -EINVAL. The file includes "linux/i2c.h", so apparently there are
>> versions of I2c.h in which the flag is undefined.
> I2C_M_DMA_SAFE is a hint for controller drivers that the buffer is DMA
> capable. It is not something the controller driver needs to support
> actively. Bailing out on this flag is wrong. Do I need to mention that
> such misconceptions are the super-downside of out-of-tree drivers? (I
> know that you are only a user of this driver, so not your fault)
>
> Happy hacking,
>
>     Wolfram
>

Hello Wolfram,

Thanks for the clarification.  I've included the core of it in my post 
on [developer.nvidia.com]
(https://forums.developer.nvidia.com/t/nvidia-driver-i2c-dev-driver-i2c-failure/228966/2)
I'm not holding my breath for a fix any time soon.

I long ago gave up on using Nvidia video cards.  Building my own copy of 
the nvidia
driver was prone to failure due to mismatches between the kernel and the 
driver.
Unfortunately, I can't control the driver that users of ddcutil use. 
There's even
a [page on ddcutil's website](https://www.ddcutil.com/nvidia) devoted to
undocumented driver settings that are often needed for I2C.

I had simplified ddcutil's most recent release (1.3.0, which inter alia 
will be in
Ubuntu 22.10) to use onlythe i2c-dev's ioctl() interface. The amount of 
code
that had to go back in was both extensive and painful.

Regards,
Sanford