lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 31 Aug 2018 16:36:16 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     linux-i2c@...r.kernel.org,
        Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [Question] When should a driver issue STOP condition?

Hi.


A problem was found in my drivers.


Before sending out patches, please let me
ask a question to make sure the right fix.


The problem is, my driver is forcibly setting
STOP condition unless the next message is read.

Please see this line:
https://github.com/torvalds/linux/blob/v4.19-rc1/drivers/i2c/busses/i2c-uniphier-f.c#L405


Obviously, it it disturbing the I2C_RDWR ioctl functionality.

Documentation/i2c/dev-interface says:
ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)
  Do combined read/write transaction without stop in between.


So, I want to be sure
what a driver should (or should not) do.

A driver should issue STOP when and only when the I2C_M_STOP flag
is set in msg->flags.

Is this correct?


In other words, do user-space programs need to explicitly set
I2C_M_STOP where the STOP condition is desired?



Then, another question popped up.

User-space programs can send a single transaction
with read() / write().

I2C_M_STOP is not set in this case.


If a driver does not take care of the STOP condition at all,
the I2C bus is never released.
Is this the right thing to do?


-- 
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists