linux-kernel - Re: [RFC/RFT 2/2] davinci: use generic memory mapped gpio for tnetv107x

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 13 Jul 2011 18:46:24 +0400
From:	Anton Vorontsov <cbouatmailru@...il.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Sekhar Nori <nsekhar@...com>, linux-kernel@...r.kernel.org,
	Kevin Hilman <khilman@...com>,
	Cyril Chemparathy <cyril@...com>,
	linux-arm-kernel@...ts.infradead.org,
	davinci-linux-open-source@...ux.davincidsp.com
Subject: Re: [RFC/RFT 2/2] davinci: use generic memory mapped gpio for
 tnetv107x

Hi Grant,

On Wed, Jul 06, 2011 at 04:02:40PM -0600, Grant Likely wrote:
[...]
> > +		{
> > +			.name	= "dat",
> > +			.start	= TNETV107X_GPIO_BASE + 0x4,
> > +			.end	= TNETV107X_GPIO_BASE + 0x4 + 0x4 - 1,
> > +		},
> > +		{
> > +			.name	= "set",
> > +			.start	= TNETV107X_GPIO_BASE + 0x10,
> > +			.end	= TNETV107X_GPIO_BASE + 0x10 + 0x4 - 1,
> > +		},
> > +		{
> > +			.name	= "dirin",
> > +			.start	= TNETV107X_GPIO_BASE + 0x1c,
> > +			.end	= TNETV107X_GPIO_BASE + 0x1c + 0x4 - 1,
> > +		},
> > +		{
> > +			.name	= "en",
> > +			.start	= TNETV107X_GPIO_BASE + 0x28,
> > +			.end	= TNETV107X_GPIO_BASE + 0x28 + 0x4 - 1,
> > +		},
> > +	},
> > +};
> 
> Wow, this ends up looking horrible. (yes, I know it is not your
> fault).  I backed off earlier on using resources for the offsets, but
> I want to change my mind again and make interface a register range +
> offsets to the control registers.

Why is this horrible? Are you proposing a single resource + platform
data for the offsets? If so, this won't look any better, but in return

- this would complicate device registration logic and driver logic
  itself (i.e. we need to allocate platform data in the arch code,
  then parse and store the structure in the driver). The platform
  data is simply unnecessary -- we have resources that describe
  memory just fine, much better then raw 'unsigned long offset';

- we lose the ability to operate on spread registers (think of
  "enable" register is down below 2MB gap, near the pinmux
  registers block);

- In the device tree, we really want to describe registers in the
  regs = <> property, because that's where memory resources should
  be. (We also want to map address position into resource name, but
  that's different story).

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/