linux-renesas-soc.vger.kernel.org archive mirror
 help / color / mirror / 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	[thread overview]
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	other threads:[~2020-07-01 14:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01  8:09 [RFC PATCH] WIP: i2c: rcar: add HostNotify support 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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).