Linux-Renesas-SoC Archive on lore.kernel.org
 help / color / Atom feed
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: linux-i2c@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	Alain Volmat <alain.volmat@st.com>
Subject: Re: [RFC PATCH] WIP: i2c: rcar: add HostNotify support
Date: Wed, 1 Jul 2020 16:57:14 +0200
Message-ID: <20200701145714.GA2808@kunai> (raw)
In-Reply-To: <20200701143738.GF3457@gnbcxd0016.gnb.st.com>


[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]


> Hum ... sorry ... I'm having some doubt about such a generic 'smbus' naming.
> I mean, stating 'smbus' within the controller node kind of says
> "I am working in SMBus mode", and not only "I am supporting Host-Notify & Alert".
> In such case, NOT having 'smbus' would mean that the driver do not support
> SMBUS and SMBus xfer and all smbus related stuff would get disabled ...
> We for sure do not want to have everybody add a smbus property in their DT
> if they support SMBus xfer for example.
> 
> This is probably too wide, don't you think ?

It would be, yet I don't think this is case.

The "smbus" property means that _additional_ SMBus restrictions apply to
that bus. Like additional timeout values, reserved addresses etc...

It does not mean that we can't use SMBus style communication on an I2C
bus. We can because we can easily emulate it. This is not an additional
restriction.

So it rather means "SMBus restrictions apply here". No such properties
means no such restrictions. But then you can't have HostNotify and Alert
because the addresses are not reserved.

We can update the binding to "smbus-restrictions" perhaps, although it
doesn't really sound nice to me. Maybe Rob also has an idea.

I'll send a patch later and then we will see what he says.

D'accord?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01  8:09 Wolfram Sang
2020-07-01  9:27 ` Wolfram Sang
2020-07-01 12:16   ` Wolfram Sang
2020-07-01 12:32     ` Alain Volmat
2020-07-01 13:21       ` Wolfram Sang
2020-07-01 13:46         ` Alain Volmat
2020-07-01 14:00           ` Wolfram Sang
2020-07-01 14:37         ` Alain Volmat
2020-07-01 14:57           ` Wolfram Sang [this message]

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=20200701145714.GA2808@kunai \
    --to=wsa+renesas@sang-engineering.com \
    --cc=alain.volmat@st.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-renesas-soc@vger.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

Linux-Renesas-SoC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-renesas-soc/0 linux-renesas-soc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-renesas-soc linux-renesas-soc/ https://lore.kernel.org/linux-renesas-soc \
		linux-renesas-soc@vger.kernel.org
	public-inbox-index linux-renesas-soc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-renesas-soc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git