[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9935938.eKOCvCAtLt@fb07-iapwap2>
Date: Fri, 12 Sep 2014 09:51:31 +0200
From: Marc Dietrich <marvin24@....de>
To: Wolfram Sang <wsa@...-dreams.de>
Cc: linux-i2c@...r.kernel.org, linux-sh@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Jean Delvare <jdelvare@...e.de>,
Magnus Damm <magnus.damm@...il.com>,
Andrey Danin <danindrey@...l.ru>, devicetree@...r.kernel.org,
Stephen Warren <swarren@...dotorg.org>
Subject: Re: [RFC 4/4] ARM: shmobile: r8a7790: adapt DTS for I2C slave support
Am Donnerstag, 11. September 2014, 16:54:22 schrieb Wolfram Sang:
> On Thu, Sep 11, 2014 at 04:52:22PM +0200, Marc Dietrich wrote:
> > Am Donnerstag, 11. September 2014, 16:40:04 schrieb Wolfram Sang:
> > > > b) could be seen as a configuration thing since the functionality
> > > > backend could be changed at runtime even.
> > >
> > > Come to think of it, not only the functionality, also the address can be
> > > changed at runtime. This makes me think it should really not be in DT
> > > after all.
> >
> > even worse, there can be multiple masters and slaves changing their role
> > on
> > the fly AFAIK. So the best dt can do is to provide an initial
> > configuration, so all drivers know where they are and where to start.
> > Everything else can be changed during runtime.
>
> Why do you want DT to be involved at all?
Imagine a device which supports both, slave or master mode. The driver needs
to know in which mode it should operate. This cannot be hard coded, because on
different boards, different modes can be used.
The point is, that if we define a dt binding for master device on slave
adapters it will be there forever. So even if it makes no sense for the
example eeprom simulator (or even our embedded controller), it may make sense
for other or future devices.
On the other hand, we had some painful discussion about that issue in the
past, so if no one else steps up to propose a good alternative binding, I will
be the last to criticize your approach.
Marc
Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)
Powered by blists - more mailing lists