On Sat, Nov 14, 2020 at 4:14 PM Richard Cochran
wrote:
>
> On Fri, Nov 13, 2020 at 05:21:43PM +0100, Arnd Bergmann wrote:
> > I've prototyped a patch that I think makes this more sensible
> > again: https://pastebin.com/AQ5nWS9e
>
> I like the behavior described in the text.
>
> Instead of this ..
On Fri, Nov 13, 2020 at 05:21:43PM +0100, Arnd Bergmann wrote:
> I've prototyped a patch that I think makes this more sensible
> again: https://pastebin.com/AQ5nWS9e
I like the behavior described in the text.
Instead of this ...
- if a built-in driver calls PTP interface functions but fails
On Fri, Nov 13, 2020 at 12:27 AM Richard Cochran
wrote:
>
> On Thu, Nov 12, 2020 at 10:21:21PM +0100, Arnd Bergmann wrote:
> > I agree that the 'imply' keyword in Kconfig is what made this a
> > lot worse, and it would be best to replace that with normal
> > dependencies.
>
> IIRC, this all starte
On Thu, Nov 12, 2020 at 10:21:21PM +0100, Arnd Bergmann wrote:
> I agree that the 'imply' keyword in Kconfig is what made this a
> lot worse, and it would be best to replace that with normal
> dependencies.
IIRC, this all started with tinification and wanting dynamic posix
clocks to be optional at
On Thu, Nov 12, 2020 at 7:19 PM Richard Cochran
wrote:
>
> On Thu, Nov 12, 2020 at 09:25:12AM +0100, Arnd Bergmann wrote:
> > This is not really getting any better. If Richard is worried about
> > Kconfig getting changed here, I would suggest handling the
> > case of PTP being disabled by returnin
On Thu, Nov 12, 2020 at 09:25:12AM +0100, Arnd Bergmann wrote:
> This is not really getting any better. If Richard is worried about
> Kconfig getting changed here, I would suggest handling the
> case of PTP being disabled by returning an error early on in the
> function, like
>
> struct am65_cpts
On Thu, Nov 12, 2020 at 12:05:25PM +0200, Grygorii Strashko wrote:
> But, as Richard mentioned [1], ptp_clock_register() may return NULL even if
> PTP_1588_CLOCK=y
> (which I can't confirm neither deny - from the fast look at
> ptp_clock_register()
> code it seems should not return NULL)
This w
On 12/11/2020 10:25, Arnd Bergmann wrote:
On Thu, Nov 12, 2020 at 2:48 AM 王擎 wrote:
On Wed, Nov 11, 2020 at 03:24:33PM +0200, Grygorii Strashko wrote:
I don't think v1 builds cleanly folks (not 100% sure, cpts is not
compiled on x86):
ret = cpts->ptp_clock ? cpts->ptp_clock
On Thu, Nov 12, 2020 at 2:48 AM 王擎 wrote:
> >> On Wed, Nov 11, 2020 at 03:24:33PM +0200, Grygorii Strashko wrote:
> >
> >I don't think v1 builds cleanly folks (not 100% sure, cpts is not
> >compiled on x86):
> >
> > ret = cpts->ptp_clock ? cpts->ptp_clock : (-ENODEV);
> >
> >ptp_cloc
>On Thu, 12 Nov 2020 09:15:05 +0800 (GMT+08:00) 王擎 wrote:
>> >Grygorii, would you mind sending a correct patch in so Wang Qing can
>> >see how it's done? I've been asking for a fixes tag multiple times
>> >already :(
>>
>> I still don't quite understand what a fixes tag means，
>> can you tell me
On Thu, 12 Nov 2020 09:15:05 +0800 (GMT+08:00) 王擎 wrote:
> >Grygorii, would you mind sending a correct patch in so Wang Qing can
> >see how it's done? I've been asking for a fixes tag multiple times
> >already :(
>
> I still don't quite understand what a fixes tag means，
> can you tell me how to
On Thu, 12 Nov 2020 10:48:37 +0800 (GMT+08:00) 王擎 wrote:
> >On Thu, 12 Nov 2020 09:15:05 +0800 (GMT+08:00) 王擎 wrote:
> >> >Grygorii, would you mind sending a correct patch in so Wang Qing can
> >> >see how it's done? I've been asking for a fixes tag multiple times
> >> >already :(
> >>
> >>
>> On Wed, Nov 11, 2020 at 03:24:33PM +0200, Grygorii Strashko wrote:
>> >
>> > Following Richard's comments v1 of the patch has to be applied [1].
>> > I've also added my Reviewed-by there.
>> >
>> > [1] https://lore.kernel.org/patchwork/patch/1334067/
>>
>> +1
>>
>> Jakub, can you please ta
On Wed, 11 Nov 2020 05:55:58 -0800 Richard Cochran wrote:
> On Wed, Nov 11, 2020 at 03:24:33PM +0200, Grygorii Strashko wrote:
> >
> > Following Richard's comments v1 of the patch has to be applied [1].
> > I've also added my Reviewed-by there.
> >
> > [1] https://lore.kernel.org/patchwork/patch/
On Wed, Nov 11, 2020 at 03:24:33PM +0200, Grygorii Strashko wrote:
>
> Following Richard's comments v1 of the patch has to be applied [1].
> I've also added my Reviewed-by there.
>
> [1] https://lore.kernel.org/patchwork/patch/1334067/
+1
Jakub, can you please take the original v1 of this patch
hi Jakub,
On 11/11/2020 14:32, Richard Cochran wrote:
On Wed, Nov 11, 2020 at 05:24:41PM +0800, Wang Qing wrote:
We always have to update the value of ret, otherwise the error value
may be the previous one. And ptp_clock_register() never return NULL
when PTP_1588_CLOCK enable.
NAK.
Your
On Wed, Nov 11, 2020 at 05:24:41PM +0800, Wang Qing wrote:
> We always have to update the value of ret, otherwise the error value
> may be the previous one. And ptp_clock_register() never return NULL
> when PTP_1588_CLOCK enable.
NAK.
Your code must handle the possibility that ptp_clock_registe
We always have to update the value of ret, otherwise the error value
may be the previous one. And ptp_clock_register() never return NULL
when PTP_1588_CLOCK enable.
Signed-off-by: Wang Qing
---
drivers/net/ethernet/ti/am65-cpts.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --
18 matches
Mail list logo
