[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200326135941.GA20841@localhost>
Date: Thu, 26 Mar 2020 06:59:41 -0700
From: Richard Cochran <richardcochran@...il.com>
To: "Y.b. Lu" <yangbo.lu@....com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"David S . Miller" <davem@...emloft.net>,
Vladimir Oltean <vladimir.oltean@....com>,
Claudiu Manoil <claudiu.manoil@....com>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH 6/6] ptp_ocelot: support 4 programmable pins
On Thu, Mar 26, 2020 at 09:34:52AM +0000, Y.b. Lu wrote:
> > 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...
Yes, and I have way to fix that. I will post a patch soon...
> 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 for explaining. Since you do have programmable pin, please
wait for my patch to fix the deadlock.
Thanks,
Richard
Powered by blists - more mailing lists