Hi Wolfram and Peter, I will give my opinion about the path chosen although it should be taken lightly.
I can see that hardware guys missed the software guys again on the development path, but since this happens more often than not, I would say it seems OK to have support for this as long as it does not make more complex (longer) standard i2c transfers. I would support to have additional mutex before mux as that will make less chance that someone forgets to lock mutex before mux and proposed solution seems valid. Regards, Crt On 5 January 2016 at 19:48, Wolfram Sang <w...@the-dreams.de> wrote: > Peter, > >> PS. needs a bunch of testing, I do not have access to all the involved hw > > First of all, thanks for diving into this topic and the huge effort you > apparently have put into it. > > It is obviously a quite intrusive series, so it needs careful review. > TBH, I can't really tell when I have the bandwidth to do that, so I hope > other people will step up. And yes, it needs serious testing. > > To all: Although I appreciate any review support, I'd think the first > thing to be done should be a very high level review - is this series > worth the huge update? Is the path chosen proper? Stuff like this. I'd > appreciate Acks or Revs for that. Stuff like fixing checkpatch warnings > and other minor stuff should come later. > > Thanks, > > Wolfram > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
