On Fri, 31 May 2013 10:08:27 -0300 Mauro Carvalho Chehab <mche...@redhat.com> wrote:
> Em Thu, 30 May 2013 21:00:01 +0200 > Jon Arne Jørgensen <jona...@jonarne.no> escreveu: > > > On Thu, May 30, 2013 at 08:33:32AM +0300, Timo Teras wrote: > > > I would rather have the platform_data provide the new table. Or > > > if you think bulk of the table will be the same for most users, > > > then perhaps add there an enum saying which table to use - and > > > name the tables according to the chip variant it applies to. > > > > > > > I think the bulk of the table will be the same for all drivers. > > It's one bit here and one bit there that needs changing. > > As the driver didn't support platform data. > > Changing to a new init table for the drivers that implement > > platform_data shouldn't cause any regressions. > > There are several things that are very bad on passing a table via > platform data: Sorry, my wording was self-conflicting. The intention was to suggest providing an enum saying which table to use. Not that the platform data would provide the whole table. > 1) you're adding saa711x-specific data at the bridge driver, > so, the saa711x code is spread on several places at the > long term; > > 2) some part of the saa711x code may override the data there, > as it is not aware about what bits should be preserved from > the new device; > > 3) due (2), latter changes on the code are more likely to > cause regressions; > > 4) also due to (2), some hacks can be needed, in order to warn > saa711x to handle some things differently. Agreed. > That's why it is a way better to add meaningful parameters telling > what bits are needed for the driver to work with the bridge. That's > also why we do this with all other drivers. Based on the latest patch, more of these bits need to be controlled individually than I figured. So yes, individual meaningful bits do make the most sense. Thanks, Timo -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
