Messages in this thread | | | Date | Thu, 20 Mar 2014 17:13:39 -0400 (EDT) | Subject | Re: [PATCH net-next v2 1/9] ptp: introduce programmable pins. | From | David Miller <> |
| |
From: Richard Cochran <richardcochran@gmail.com> Date: Thu, 20 Mar 2014 21:43:08 +0100
> On Mon, Mar 17, 2014 at 09:25:34PM -0400, David Miller wrote: >> >> This locking seems unnecessarily complex to me. You should be able to >> do the stateless sanity checks, take the mutex, then do all of the >> rest of the operations until the end of the function before >> dropping the lock. >> >> So just take the lock once over the operations that need it. > > The idea was to avoid holding the mutex when invoking the driver > callbacks (.verify and .enable). Mostly this is my paranoia that some > bad driver will call back into the core via ptp_set_pinfunc().
During my review, I checked all the implementations of said methods and they all universally adjust software state and return.
> But you are right that the result is overly complex. I'll make the > callers of ptp_set_pinfunc hold the mutex, and so the set path will > look just like the get path.
Thanks.
| |