linux-kernel - Re: [PATCH v3 5/6] docs: i2c: summary: document 'local' and 'remote' targets

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 21 Jun 2024 01:38:33 +0200
From: Andi Shyti <andi.shyti@...nel.org>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>, 
	Easwar Hariharan <eahariha@...ux.microsoft.com>, linux-i2c@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 5/6] docs: i2c: summary: document 'local' and 'remote'
 targets

Hi Wolfram,

On Wed, Jun 19, 2024 at 09:10:26AM GMT, Wolfram Sang wrote:
> > > "Synonyms" from patch 6 does say that controller/target is preferred but
> > > couched it in the caveat "If speaking about I2C in general" and
> > > adapter/client when "discuss[ing] implementation details." I was trying
> > > to give space for an unambiguous recommendation.
> > 
> > Exactly, this is what I referred to in my previous e-mails.
> > These two statements sound a bit ambiguous to me, as well.
> 
> Okay, here is my proposed update:
> 
> ===
> 
> diff --git a/Documentation/i2c/summary.rst b/Documentation/i2c/summary.rst
> index 90f46f1504fe..579a1c7df200 100644
> --- a/Documentation/i2c/summary.rst
> +++ b/Documentation/i2c/summary.rst
> @@ -67,9 +67,9 @@ Synonyms
>  
>  As mentioned above, the Linux I2C implementation historically uses the terms
>  "adapter" for controller and "client" for target. A number of data structures
> -have these synonyms in their name. So, to discuss implementation details, it
> -might be easier to use these terms. If speaking about I2C in general, the
> -official terminology is preferred.
> +have these synonyms in their name. So, when discussing implementation details,
> +you should be aware of these terms as well. The official wording is preferred,
> +though.

ACK!

> ===
> 
> I don't want to be stricter than "preferred". If someone still wants to
> use 'struct i2c_client *client' this is fine with me.

Sure, let's see how it goes.

> > Maybe we are wasting time at discussing minor details, but I
> > consider this part important in order to give way to the major
> > refactoring that Wolfram started at the beginning.
> 
> The refactoring only affects "master/slave" not "adapter/client". We are
> 
> aligned here, aren't we?

Yes, of course. And I'm not really asking for the totality of the
"client"'s to be replaced, rather than, when replacing slave, to
choose "target" over "client" whenever possible(*).

Thanks, Wolfram,

Andi

(*) E.g. if in a file "client" is used a lot, doesn't make sense
    to go against the trend and use "target".