All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alain Volmat <alain.volmat@st.com>
To: Wolfram Sang <wsa@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	<robh+dt@kernel.org>, <mark.rutland@arm.com>,
	<pierre-yves.mordret@st.com>, <mcoquelin.stm32@gmail.com>,
	<alexandre.torgue@st.com>, <linux-i2c@vger.kernel.org>,
	<devicetree@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <fabrice.gasnier@st.com>
Subject: Re: [PATCH 4/4] i2c: stm32f7: Add SMBus-specific protocols support
Date: Tue, 30 Jun 2020 11:31:35 +0200	[thread overview]
Message-ID: <20200630093135.GC5652@gnbcxd0016.gnb.st.com> (raw)
In-Reply-To: <20200630064050.GA996@ninjato>

Hi Wolfram,

> I meant a generic binding for the host-controller. It could be seen as a
> HW description if we need HostNotify on that bus or not.
> 
> Maybe it becomes more clear with the R-Car I2C controller as an example.
> It only supports one slave address. If I want HostNotify there, I can't
> use another slave backend. Now, it could be that I need the slave EEPROM
> backend, although there is a HostNotify capable device on the bus. So, I
> am leaning to have a generic "host-notify" binding for the host.
> 
> I consider platform_data legacy. If we use device_property, we should be
> safe regarding all current and future HW descriptions, or?

Ok, understood. Fine for me that way as well. I am just a little worrying that
the "host-notify" can now be present in both controller AND slave nodes
and might be a bit hard to understand. At the same time I don't have a better
proposal for naming the binding for the controller.

Please do not consider serie v2 I just posted few days ago and I will
post a serie v3 updating the binding information and using the host-notify
binding in the i2c-stm32f7 driver.

Alain

WARNING: multiple messages have this Message-ID (diff)
From: Alain Volmat <alain.volmat@st.com>
To: Wolfram Sang <wsa@kernel.org>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	alexandre.torgue@st.com, linux-kernel@vger.kernel.org,
	pierre-yves.mordret@st.com, robh+dt@kernel.org,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	linux-i2c@vger.kernel.org, mcoquelin.stm32@gmail.com,
	fabrice.gasnier@st.com, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 4/4] i2c: stm32f7: Add SMBus-specific protocols support
Date: Tue, 30 Jun 2020 11:31:35 +0200	[thread overview]
Message-ID: <20200630093135.GC5652@gnbcxd0016.gnb.st.com> (raw)
In-Reply-To: <20200630064050.GA996@ninjato>

Hi Wolfram,

> I meant a generic binding for the host-controller. It could be seen as a
> HW description if we need HostNotify on that bus or not.
> 
> Maybe it becomes more clear with the R-Car I2C controller as an example.
> It only supports one slave address. If I want HostNotify there, I can't
> use another slave backend. Now, it could be that I need the slave EEPROM
> backend, although there is a HostNotify capable device on the bus. So, I
> am leaning to have a generic "host-notify" binding for the host.
> 
> I consider platform_data legacy. If we use device_property, we should be
> safe regarding all current and future HW descriptions, or?

Ok, understood. Fine for me that way as well. I am just a little worrying that
the "host-notify" can now be present in both controller AND slave nodes
and might be a bit hard to understand. At the same time I don't have a better
proposal for naming the binding for the controller.

Please do not consider serie v2 I just posted few days ago and I will
post a serie v3 updating the binding information and using the host-notify
binding in the i2c-stm32f7 driver.

Alain

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-06-30  9:32 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05  5:51 [PATCH 0/4] stm32-f7: Addition of SMBus Alert / Host-notify features Alain Volmat
2020-05-05  5:51 ` Alain Volmat
2020-05-05  5:51 ` [PATCH 1/4] i2c: smbus: add core function handling SMBus host-notify Alain Volmat
2020-05-05  5:51   ` Alain Volmat
2020-05-11  8:26   ` Pierre Yves MORDRET
2020-05-11  8:26     ` Pierre Yves MORDRET
2020-05-23 10:46   ` Wolfram Sang
2020-05-23 10:46     ` Wolfram Sang
2020-05-26 10:23     ` Alain Volmat
2020-05-26 10:23       ` Alain Volmat
2020-05-05  5:51 ` [PATCH 2/4] i2c: addition of client reg/unreg callbacks Alain Volmat
2020-05-05  5:51   ` Alain Volmat
2020-05-11  8:28   ` Pierre Yves MORDRET
2020-05-11  8:28     ` Pierre Yves MORDRET
2020-05-23 10:49   ` Wolfram Sang
2020-05-23 10:49     ` Wolfram Sang
2020-05-05  5:51 ` [PATCH 3/4] dt-bindings: i2c-stm32: add SMBus Alert bindings Alain Volmat
2020-05-05  5:51   ` Alain Volmat
2020-05-13  2:19   ` Rob Herring
2020-05-13  2:19     ` Rob Herring
2020-05-13  5:42     ` Alain Volmat
2020-05-13  5:42       ` Alain Volmat
2020-05-18 10:53       ` Alain Volmat
2020-05-18 10:53         ` Alain Volmat
2020-05-23 10:36       ` wsa
2020-05-23 10:36         ` wsa
2020-05-26 10:31         ` Alain Volmat
2020-05-26 10:31           ` Alain Volmat
2020-05-05  5:51 ` [PATCH 4/4] i2c: stm32f7: Add SMBus-specific protocols support Alain Volmat
2020-05-05  5:51   ` Alain Volmat
2020-05-11  8:27   ` Pierre Yves MORDRET
2020-05-11  8:27     ` Pierre Yves MORDRET
2020-05-23 11:01   ` Wolfram Sang
2020-05-23 11:01     ` Wolfram Sang
2020-05-26 10:39     ` Alain Volmat
2020-05-26 10:39       ` Alain Volmat
2020-06-30  6:40       ` Wolfram Sang
2020-06-30  6:40         ` Wolfram Sang
2020-06-30  9:31         ` Alain Volmat [this message]
2020-06-30  9:31           ` Alain Volmat
2020-06-30 15:11           ` Wolfram Sang
2020-06-30 15:11             ` Wolfram Sang

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=20200630093135.GC5652@gnbcxd0016.gnb.st.com \
    --to=alain.volmat@st.com \
    --cc=alexandre.torgue@st.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fabrice.gasnier@st.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mark.rutland@arm.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=pierre-yves.mordret@st.com \
    --cc=robh+dt@kernel.org \
    --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.