On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab
<mche...@infradead.org> wrote:
> I don't like the idea of creating structs grouping those parameters. While for
> certain devices this may mean a more direct approach, for others, this may
> not make sense, due to the way their API's were implemented (for example,
> devices with firmware may need several calls to get all those info).

There is some value in providing grouping the results in a single
request - in many cases the data is based off of the same internal
registers, and Manu's proposed approach allows for a more "atomic"
response.  The fact that we currently do the status, SNR, strength,
and UNC/BER in separate calls is one reason that people sometimes see
inconsistent results in the output of tools like zap.  As an example,
they can see lines in the zap output where the lock is lost but SNR
appears fine.

In the case where the driver servicing the query needs to do three
calls, it could be slightly more expensive, but only if we believe
that it is commonplace to ask for a subset of the stats.


Devin J. Heitmueller - Kernel Labs
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

Reply via email to