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  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <97ff6fe9-0dfc-4116-99a0-7efcdd16f8dc@gmail.com>
Date: Sun, 10 Aug 2025 11:10:15 +0200
From: Jonas Jelonek <jelonek.jonas@...il.com>
To: Markus Elfring <Markus.Elfring@....de>, linux-i2c@...r.kernel.org,
 devicetree@...r.kernel.org, Andi Shyti <andi.shyti@...nel.org>,
 Chris Packham <chris.packham@...iedtelesis.co.nz>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Conor Dooley <conor+dt@...nel.org>,
 Harshal Gohel <hg@...onwunderlich.de>,
 Markus Stockhausen <markus.stockhausen@....de>,
 Sven Eckelmann <sven@...fation.org>
Subject: Re: [PATCH v5 07/11] i2c: rtl9300: move setting SCL frequency to
 config_io


On 10.08.2025 10:49, Markus Elfring wrote:
> …
>> +++ b/drivers/i2c/busses/i2c-rtl9300.c
> …
>> +static int mshv_vtl_sint_ioctl_set_eventfd(struct mshv_vtl_set_eventfd __user *arg)
>> +{
> …
>> @@ -244,7 +245,7 @@ static int rtl9300_i2c_smbus_xfer(struct i2c_adapter *adap, u16 addr, unsigned s
>>  
>>  	mutex_lock(&i2c->lock);
>>  	if (chan->sda_num != i2c->sda_num) {
>> -		ret = rtl9300_i2c_config_io(i2c, chan->sda_pin);
>> +		ret = rtl9300_i2c_config_io(i2c, chan);
>>  		if (ret)
>>  			goto out_unlock;
> …
>
> Under which circumstances would you become interested to apply a statement
> like “guard(mutex)(&i2c->lock);”?
> https://elixir.bootlin.com/linux/v6.16/source/include/linux/mutex.h#L225

Didn't know about that before but no objections against it. Can integrate that
in the next version.

The link Sven posted was quite helpful on that, thanks! This looks quite similar
to how it is in Rust, that you just lock/guard it and it is dropped at the end of
the current scope. I like that :)

> Regards,
> Markus

Best regards,
Jonas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ