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:	Fri, 19 Jun 2009 10:42:22 +0200
From:	Linus Walleij <linus.ml.walleij@...il.com>
To:	Ben Dooks <ben-linux@...ff.org>
Cc:	linux-kernel@...r.kernel.org, sameo@...ux.intel.com,
	linux-i2c@...r.kernel.org,
	Linus Walleij <linus.walleij@...ricsson.com>
Subject: Re: [PATCH 1/1] MFD: Add U300 AB3100 core support v3

I was revisiting this in my mind:

2009/5/20 Ben Dooks <ben-linux@...ff.org>:
> On Tue, May 19, 2009 at 04:36:50PM +0200, Linus Walleij wrote:
(...)
>> +/*
>> + * Here we define all the platform devices that appear
>> + * as children of the AB3100. These are regular platform
>> + * devices with the IORESOURCE_IO .start and .end set
>> + * to correspond to the internal AB3100 register range
>> + * mapping to the corresponding subdevice.
>> + */
>> +
>> +#define AB3100_DEVICE(devname, devid, regstart, regend)              \
>> +static struct resource ab3100_##devname##_resource[] = {     \
>> +     {                                                       \
>> +             .start  = regstart,                             \
>> +             .end    = regend,                               \
>> +             .flags  = IORESOURCE_IO,                        \
>> +     }                                                       \
>
> is IORESOURCE_IO a good idea here, we may need to add some form of
> flag to say 'generic data' and for the driver core to not try and
> register it with any of the ioport or iomem structures.

I face the issue of adding sub-drivers to the AB3100 which will likely
be the same for other chips in the same series, so that say
drivers/rtc-ab3100.c will be used for all AB3xxx chips.
Register X thru X+size-1 (maps to .start and .end) will be
used for a certain subdevice.

So naturally I want these drivers to be relative to some base I2C
register adress and this needs to be passed down as a resource.
(Each I2C device has max 256 registers only for natural resons,
but may still contain several functions.)

Type, as defined in ioport.h is only four unique bits and all four
are taken:

#define IORESOURCE_TYPE_BITS    0x00000f00      /* Resource type */
#define IORESOURCE_IO           0x00000100
#define IORESOURCE_MEM          0x00000200
#define IORESOURCE_IRQ          0x00000400
#define IORESOURCE_DMA          0x00000800

(Pretty generic.)

There is no space for any IORESOURCE_GENERIC or so.

So putting in a resource of type IORESOURCE_IO is still the
best thing I can think of here, any other suggestions?
(I can think of kludgy things like using the bus-specific bits 7-0.)

Yours,
Linus Walleij
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ