-----Original Message-----
From: Dan Carpenter <redacted>
Sent: Friday, June 23, 2023 5:14 PM
To: Sai Krishna Gajula <redacted>
Cc: davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
pabeni@redhat.com; netdev@vger.kernel.org; linux-
kernel@vger.kernel.org; Sunil Kovvuri Goutham [off-list ref];
maciej.fijalkowski@intel.com; Naveen Mamindlapalli
[off-list ref]
Subject: Re: [net PATCH v2] octeontx2-af: Move validation of ptp
pointer before its usage

On Fri, Jun 23, 2023 at 11:28:19AM +0000, Sai Krishna Gajula wrote:

quoted

quoted

This probe function is super weird how it returns success on the failure

path.

quoted

quoted

One concern, I had initially was that if anything returns
-EPROBE_DEFER then we cannot recover.  That's not possible in the
current code, but it makes me itch...  But here is a different crash.

In few circumstances, the PTP device is probed before the AF device in
the driver. In such instance, -EPROBE_DEFER is used.
-- EDEFER_PROBE is useful when probe order changes. Ex: AF driver probes

before PTP.

quoted

You're describing how -EPROBE_DEFER is *supposed* to work.  But that's not
what this driver does.

If the AF driver is probed before the PTP driver then ptp_probe() should
return -EPROBE_DEFER and that would allow the kernel to automatically retry
ptp_probe() later.  But instead of that, ptp_probe() returns success.  So I
guess the user would have to manually rmmod it and insmod it again?  So,
what I'm saying I don't understand why we can't do this in the normal way.

The other thing I'm saying is that the weird return success on error stuff
hasn't been tested or we would have discovered the crash through testing.

regards,
dan carpenter

As suggested, we will return error in ptp_probe in case of any failure conditions. In this case AF driver continues without PTP support.
When the AF driver is probed before PTP driver , we will defer the AF probe. Hope these changes are inline with your view.
I will send a v3 patch with these changes. 

Regards,
Sai