public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: "Voss, Nikolaus" <N.Voss@weinmann.de>
Cc: "'linux-i2c@vger.kernel.org'" <linux-i2c@vger.kernel.org>,
	"'linux-arm-kernel@lists.infradead.org'" 
	<linux-arm-kernel@lists.infradead.org>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
	"'ben-linux@fluff.org'" <ben-linux@fluff.org>
Subject: Re: [PATCH v7 3/5] drivers/i2c/busses/i2c-at91.c: add new driver
Date: Thu, 24 Nov 2011 16:47:35 +0000	[thread overview]
Message-ID: <201111241647.35818.arnd@arndb.de> (raw)
In-Reply-To: <EF2E73589CA71846A15D0B2CDF79505D087B45007C@wm021.weinmann.com>

On Thursday 24 November 2011, Voss, Nikolaus wrote:
> > Aside from the flamewar in that thread, my impression is that in general
> > people (me certainly) prefer to have driver-local workarounds be expressed
> > in a driver specific way, not in a platform or architecture specific way
> > because that makes the driver less portable.
> 
> I guess I see your point now. So you want something like pdev.has_bugX to be
> set by mach setup and later check this flag in the driver?

Yes, that would be the idea. I would not introduce platform_data for one
driver just for this though, because we are generally moving away from
platform_data towards device tree probing.

You can do it with a match table that has two entries with different
names for the two kinds of device that you need to distinguish and
set the platform_device_id->driver_data field to '1' for the type
that needs the fixup.

> > > > #define       AT91_TWI_MMR            0x00000004
> > > > #define       AT91_TWI_IADRSZ         0x00000300
> > > > #define       AT91_TWI_IADRSZ_NO      0x00000000
> > > > #define       AT91_TWI_IADRSZ_1       0x00000100
> > > > ...
> > >
> > > I agree, but this header file was already used by the old driver and
> > > converting would add possible errors to register definitions which are
> > > not (yet) used. That's why I've left it as is and just made it a local
> > > include.
> > 
> > But you are presenting the driver as a new one, so you should be
> > prepared to get review comments like any other new code.
> > 
> > Please at least move the data into the main driver file to get rid of
> > the header file.
> 
> I didn't want to appear ignorant about this, I actually appreciate your
> comment. I just wanted to point out that there might be a reason to keep
> the old file which you weren't aware of (because I presented this as a new
> driver). So, I will move the register definitions to the main driver.

Ok, good. Moving it into the driver is really the important part anyway,
and I understand your reasoning for not wanting to modify the definitions,
it just didn't apply to the one of the two comments I made about the header.

	Arnd

  reply	other threads:[~2011-11-24 16:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-23 15:35 [PATCH v7 0/5] AT91: replace broken TWI driver i2c-at91.c Nikolaus Voss
2011-11-08 10:49 ` [PATCH v7 1/5] drivers/i2c/busses/i2c-at91.c: remove broken driver Nikolaus Voss
2011-11-08 10:49 ` [PATCH v7 3/5] drivers/i2c/busses/i2c-at91.c: add new driver Nikolaus Voss
2011-11-23 16:18   ` Arnd Bergmann
2011-11-24 10:33     ` Voss, Nikolaus
2011-11-24 15:39       ` Arnd Bergmann
2011-11-24 16:36         ` Voss, Nikolaus
2011-11-24 16:47           ` Arnd Bergmann [this message]
2011-11-08 11:09 ` [PATCH v7 2/5] Replace clk_lookup.con_id with clk_lookup.dev_id entries for twi clk Nikolaus Voss
2011-11-08 11:11 ` [PATCH v7 4/5] G45 TWI: remove open drain setting for twi function gpios Nikolaus Voss
2011-11-18 11:38 ` [PATCH v7 5/5] i2c-at91.c: add SMBUS_READ_BLOCK_DATA functionality Nikolaus Voss
2011-11-23 23:32 ` [PATCH v7 0/5] AT91: replace broken TWI driver i2c-at91.c Ben Dooks
2011-11-24  6:33   ` Voss, Nikolaus
2011-11-24 22:13     ` Ryan Mallon
2011-11-25 15:42 ` Hubert Feurstein
2011-12-28 13:36   ` AW: " Carsten Behling
2012-01-11 14:06     ` Voss, Nikolaus

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=201111241647.35818.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=N.Voss@weinmann.de \
    --cc=ben-linux@fluff.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@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