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  linux-hardening  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 <>
        Wolfram Sang <>
Cc:     Linux Kernel Mailing List <>
Subject: [Question] When should a driver issue STOP condition?


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:

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