Messages in this thread | | | From | "Y.b. Lu" <> | Subject | RE: [PATCH 6/6] ptp_ocelot: support 4 programmable pins | Date | Thu, 26 Mar 2020 09:34:52 +0000 |
| |
Hi Richard,
> -----Original Message----- > From: Richard Cochran <richardcochran@gmail.com> > Sent: Wednesday, March 25, 2020 9:42 PM > To: Y.b. Lu <yangbo.lu@nxp.com> > Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org; David S . Miller > <davem@davemloft.net>; Vladimir Oltean <vladimir.oltean@nxp.com>; > Claudiu Manoil <claudiu.manoil@nxp.com>; Andrew Lunn <andrew@lunn.ch>; > Vivien Didelot <vivien.didelot@gmail.com>; Florian Fainelli > <f.fainelli@gmail.com>; Alexandre Belloni <alexandre.belloni@bootlin.com>; > Microchip Linux Driver Support <UNGLinuxDriver@microchip.com> > Subject: Re: [PATCH 6/6] ptp_ocelot: support 4 programmable pins > > On Wed, Mar 25, 2020 at 03:08:46AM +0000, Y.b. Lu wrote: > > > The calling should be like this, > > ptp_set_pinfunc (hold pincfg_mux) > > ---> ptp_disable_pinfunc > > ---> .enable > > ---> ptp_find_pin (hold pincfg_mux) > > I see. The call > > ptp_disable_pinfunc() --> .enable() > > is really > > ptp_disable_pinfunc() --> .enable(on=0) > > or disable. > > All of the other drivers (except mv88e6xxx which has a bug) avoid the > deadlock by only calling ptp_find_pin() when invoked by .enable(on=1); > > Of course, that is horrible, and I am going to find a way to fix it.
Thanks a lot. Do you think it is ok to move protection into ptp_set_pinfunc() to protect just pin_config accessing? ptp_disable_pinfunc() not touching pin_config could be out of protection. But it seems indeed total ptp_set_pinfunc() should be under protection...
> > For now, maybe you can drop the "programmable pins" feature for your > driver? After all, the pins are not programmable.
I still want to confirm, did you mean the deadlock issue? Or you thought the pin supports only PTP_PF_PEROUT in hardware? I could modify commit messages to indicate the pin supports both PTP_PF_PEROUT and PTP_PF_EXTTS, and PTP_PF_EXTTS support will be added in the future. Thanks a lot.
> > Thanks, > Richard
| |