[lkml]   [2011]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v5 2/4] gpiolib: Add ability to get GPIO direction
    > I don't object to a callback hook.  My objection is how it is bodged
    > on to work around limitations to the direction being cached in the
    > flags variable. I want to see a solution that either depends entirely
    > on the callback, or completely fixes the problems with the cached
    > value by allowing the driver to update it.

    Doing it all by callback might actually fix a lot of the problems because
    it can handle all kinds of 'unknowns'. If the callbacks for set/get
    optionally pass a char buffer as well even the /proc interface just comes
    out in the wash as the device can return a string to populate the status
    or to be parsed (obviously with most h/w using the default method which
    is in/out)

    However who then does the enforcement of gpio_foo calls if the flag is
    not cached, does that end up in each driver or is there still a cache of
    some form ?

    Not sure updating the interface is that hard either - we've done it
    before with other layers simply by starting off with

    if (foo->ops->method)
    foo->ops->method(foo, bar);
    else {
    old fixed method + glue

    (or by forcing foo->ops->method on init to point to a default handler,
    but that breaks making ops const)


     \ /
      Last update: 2011-03-08 13:17    [W:0.046 / U:10.196 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site