[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4FF0051BF59A4F94A5CB49DFD97F9D4A@subhasishg>
Date: Mon, 30 May 2011 20:58:35 +0530
From: "Subhasish Ghosh" <subhasish@...tralsolutions.com>
To: "Arnd Bergmann" <arnd@...db.de>
Cc: "Greg KH" <greg@...ah.com>,
"Mark Brown" <broonie@...nsource.wolfsonmicro.com>,
"Nori, Sekhar" <nsekhar@...com>,
<linux-arm-kernel@...ts.infradead.org>,
<davinci-linux-open-source@...ux.davincidsp.com>,
<sachi@...tralsolutions.com>,
"Samuel Ortiz" <sameo@...ux.intel.com>,
"open list" <linux-kernel@...r.kernel.org>,
"Watkins, Melissa" <m-watkins@...com>
Subject: Re: [PATCH v4 01/11] mfd: add pruss mfd driver
> On Monday 30 May 2011, Subhasish Ghosh wrote:
>> >
>> > During the time when the drivers are in staging, all files need to
>> > be in the same directory, including the header and the drivers using
>> > it.
>> > They can get moved at the time when the driver gets turned into
>> > a regular non-staging driver.
>>
>> OK, so the UART implementation needs to be moved into staging as well ?
>>
>> And what about the boardfile changes, array of mfd_cells implementation
>> etc.
>
> All of that, too.
>
> Note that you are citing exactly the points that are the reason for the
> discussion we are having. The mfd_cells are the main concern for the cases
> where the information is not static.
Yes, but by destroying the structure that I have currently in the platform
files,
I will be basically going backwards.
If only the platform_data is what is going to change with some additions
of sysfs attributes, then will it be correct to have the platform data
as an empty pointer and keep the rest as is ?
That way, I can keep the platform changes untouched and move just
the drivers into staging.
I cannot destroy the complete platform code as there are other drivers
(PRUSS UIO) depending on them.
--
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