Re: [PATCH] adding support for setting bus parameters in sub device

[Robert Jarzmik <robert.jarzmik@free.fr>]

Let's begin the maintainers party.

> A board designer knows what the host supports, knows what the sensor 
> supports, and knows if he added any inverters on the board, and based on 
> all that information he can just setup these parameters for the sensor 
> chip. Settings that are fixed on the sensor chip he can just ignore, he 
> only need to specify those settings that the sensor really needs.
I don't think that's true Hans.
A lot of mainline's kernel boards have been written by passionate people, having
no access to boards layout (for pxa, the includes corgi, tosa, hx4700, mioa701,
all palm series, ...)

For these people, having an "autonegociation algorithm" is one less thing to
bother about.

> > In my opinion you should always want to set this explicitly. This is not
> > something you want to leave to chance. Say you autoconfigure this. Now
> > someone either changes the autoconf algorithm, or a previously undocumented
> > register was discovered for the i2c device and it can suddenly configure the
> > polarity of some signal that was previously thought to be fixed, or something
> > else happens causing a different polarity to be negotiated.
If you're afraid of side effects, you can force the polarity in board code with
the current framework.

If we reduce the current autonegociation code to polarity (forget bus witdh,
...) :
 - if board coder sets unique polarities, they'll be chosen (1)
 - if board coder doesn't set them, the autonegociation algorithm will choose
   (2)

What you want to do is to force all board developers to explicitely polarities,
to only use subset (1) of current negociation algorithm. I see no technical
point motivating this. The existing algorithm is richer.

Personnaly, I'll consider that reducing soc_camera framework to (1) instead of
(1)+(2) is a regretable regression. As part of the board maintaineers having no
access to my board's design, I find the current framework a help.

I still don't understand clearly why delete (2) from current framework. As I
said, "the board designer knows polarities" doesn't stand in our communauty
where board are developped without prior knowledge.

So Hans, why do you want to delete (2) ?

--
Robert