On Fri, 6 Aug 2010, Russell King - ARM Linux wrote:
> On Fri, Aug 06, 2010 at 01:02:24PM +0300, Ohad Ben-Cohen wrote:
> > We have Russell's suggestion which is nice and simple, but it has the
> > 1 device limitation.
>
> You could make it generic by doing something like this:
>
> #define set_dev
On Fri, Aug 06, 2010 at 01:02:24PM +0300, Ohad Ben-Cohen wrote:
> We have Russell's suggestion which is nice and simple, but it has the
> 1 device limitation.
You could make it generic by doing something like this:
#define set_device_data(name, type, index, data)\
({
On Fri, Aug 6, 2010 at 10:07 AM, Linus Walleij
wrote:
> 2010/8/4 Ohad Ben-Cohen :
>> On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux
>>>
>>> Why not arrange for a small piece of code to be built into the kernel
>>> when this driver is selected as a module or built-in, which handles
>>> th
2010/8/4 Ohad Ben-Cohen :
> On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux
>>
>> Why not arrange for a small piece of code to be built into the kernel
>> when this driver is selected as a module or built-in, which handles
>> the passing of platform data to the driver?
>
> It's interesting
On Wed, Aug 4, 2010 at 2:42 PM, Ohad Ben-Cohen wrote:
> On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux
> wrote:
>> On Wed, Aug 04, 2010 at 02:24:39PM +0300, Ohad Ben-Cohen wrote:
>>> On Tue, Aug 3, 2010 at 5:17 PM, Vitaly Wool wrote:
>>> > On Mon, Aug 2, 2010 at 11:35 PM, Ohad Ben-Cohe
On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux
wrote:
> On Wed, Aug 04, 2010 at 02:24:39PM +0300, Ohad Ben-Cohen wrote:
>> On Tue, Aug 3, 2010 at 5:17 PM, Vitaly Wool wrote:
>> > On Mon, Aug 2, 2010 at 11:35 PM, Ohad Ben-Cohen wrote:
>> >> I'm honestly trying to understand your concern
On Wed, Aug 04, 2010 at 02:24:39PM +0300, Ohad Ben-Cohen wrote:
> Hi Vitaly,
>
> On Tue, Aug 3, 2010 at 5:17 PM, Vitaly Wool wrote:
> > On Mon, Aug 2, 2010 at 11:35 PM, Ohad Ben-Cohen wrote:
> >> I'm honestly trying to understand your concerns, but I'm afraid that
> >> just saying "it's a hack"
Hi Vitaly,
On Tue, Aug 3, 2010 at 5:17 PM, Vitaly Wool wrote:
> On Mon, Aug 2, 2010 at 11:35 PM, Ohad Ben-Cohen wrote:
>> I'm honestly trying to understand your concerns, but I'm afraid that
>> just saying "it's a hack" is not too informative. Can you please
>> explain what do you think is techn
Hi Ohad,
On Mon, Aug 2, 2010 at 11:35 PM, Ohad Ben-Cohen wrote:
> I'm honestly trying to understand your concerns, but I'm afraid that
> just saying "it's a hack" is not too informative. Can you please
> explain what do you think is technically wrong with the proposed
> solution ? is it not gene
Hi Vitaly,
On Mon, Aug 2, 2010 at 7:25 PM, Vitaly Wool wrote:
> On Mon, Aug 2, 2010 at 5:54 PM, Ohad Ben-Cohen wrote:
>> SPI is using these spi_board_info tables to populate the SPI device
>> trees. These tables are registered early at the board-specific init
>> code, and are later used by SPI c
Hi Ohad,
On Mon, Aug 2, 2010 at 5:54 PM, Ohad Ben-Cohen wrote:
> SPI is using these spi_board_info tables to populate the SPI device
> trees. These tables are registered early at the board-specific init
> code, and are later used by SPI core to populate the devices when the
> SPI master controll
Hi Vitaly,
On Thu, Jul 29, 2010 at 7:16 PM, Vitaly Wool wrote:
> On Thu, Jul 29, 2010 at 8:00 AM, Ohad Ben-Cohen wrote:
>>> To my understanding, this data doesn't belong to mmc_host. It's not a
>>> host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's
>>> totally unrelated to hos
Hi Ohad,
On Thu, Jul 29, 2010 at 8:00 AM, Ohad Ben-Cohen wrote:
>> To my understanding, this data doesn't belong to mmc_host. It's not a
>> host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's
>> totally unrelated to host.
>>
>> I think a cleaner way would be to introduce somethi
Hi Vitaly,
On Wed, Jul 28, 2010 at 10:47 PM, Vitaly Wool wrote:
> On Wed, Jul 21, 2010 at 7:33 PM, Ohad Ben-Cohen wrote:
>> Add support to set/get mmc_host private embedded
>> data.
>>
>> This is needed to allow software to dynamically
>> create (and remove) SDIO functions which represents
>> em
Hi Ohad,
On Wed, Jul 21, 2010 at 7:33 PM, Ohad Ben-Cohen wrote:
> Add support to set/get mmc_host private embedded
> data.
>
> This is needed to allow software to dynamically
> create (and remove) SDIO functions which represents
> embedded SDIO devices.
>
> @@ -209,6 +209,8 @@ struct mmc_host {
Add support to set/get mmc_host private embedded
data.
This is needed to allow software to dynamically
create (and remove) SDIO functions which represents
embedded SDIO devices.
Typically, it will be used to set the context of
a driver that is creating a new SDIO function
(and would then expect t
16 matches
Mail list logo
