All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Wolfram Sang <wsa@kernel.org>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	Krzysztof Piotr Oledzki <ole@ans.pl>
Subject: Re: [PATCH] i2c: core: Lock address during client device instantiation
Date: Fri, 16 Aug 2024 13:33:45 +0200	[thread overview]
Message-ID: <271bc1f6-966d-4567-88e7-4bfb82d979aa@gmail.com> (raw)
In-Reply-To: <Zr8ar4SCtYAiq-U0@shikoro>

On 16.08.2024 11:23, Wolfram Sang wrote:
> Hi Heiner,
> 
>> I didn't find a single dts(i) with a 10bit i2c device. Because you said
> 
> In all those years, I didn't even find a device supporting 10 bit
> addresses. And I really looked especially for them. Some controllers
> offer 10-bit support in target mode, but that's all I found.
> 
I found LM8330 which supports 10 bit addressing. However the upper three
bits of supported addresses are always zero, so there's no benefit in
using 10 bit addressing.

> Also, there is only one user of I2C_CLIENT_TEN, and this is only a hack
> to allow instantiating the device at address 0x00. No actual 10-bit
> usage involved. I will remove this as a first step, because this hack is
> terrible anyhow.
> 
>> that you're tempted to remove 10 bit support: Could the device tree part
>> be a starting point?
> 
> I don't really have a roadmap how to deprecate 10 bit support. Because
> it is exported to userspace, the first question is if we can deprecate
> it, after all. But not much bandwidth even for that, currently.
> 
Yes, removing UAPI functionality may be tricky.
What I meant was that as a starting point we could replace the following in
of_i2c_get_board_info() with an error message stating that 10 bit mode
support has been removed.

	if (addr & I2C_TEN_BIT_ADDRESS) {
		addr &= ~I2C_TEN_BIT_ADDRESS;
		info->flags |= I2C_CLIENT_TEN;
	}

> Happy hacking,
> 
>    Wolfram
> 
Heiner

  reply	other threads:[~2024-08-16 11:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-13 21:39 [PATCH] i2c: core: Lock address during client device instantiation Heiner Kallweit
2024-08-14 11:14 ` Wolfram Sang
2024-08-14 20:07   ` Heiner Kallweit
2024-08-14 20:25     ` Wolfram Sang
2024-08-16  6:17   ` Heiner Kallweit
2024-08-16  9:23     ` Wolfram Sang
2024-08-16 11:33       ` Heiner Kallweit [this message]
2024-08-16 14:49         ` Wolfram Sang
2024-08-15 11:29 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=271bc1f6-966d-4567-88e7-4bfb82d979aa@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=ole@ans.pl \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=wsa@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.