> > While testing this, I think I have discovered a small mistake on my
> > previous, Nuttx-side PR, which slipped by me and by revision: "ret"
> > might be used uninitialized now because I removed the assignment on
> > stm32_fdcan_sock:1976
> Yes, please make a PR to fix that!! When it's ready, p
On Wed, Apr 16, 2025 at 1:25 AM Carlos Sanchez
wrote:
> Related PR on the apps side, to make slcan work after the "bitrate no
> longer brings interface up" change:
> https://github.com/apache/nuttx-apps/pull/3059
>
> While testing this, I think I have discovered a small mistake on my
> previous,
On Tue, Apr 15, 2025 at 1:25 PM Carlos Sanchez
wrote:
> Related PR on the apps side, to make slcan work after the "bitrate no
> longer brings interface up" change:
> https://github.com/apache/nuttx-apps/pull/3059
>
> While testing this, I think I have discovered a small mistake on my
> previous,
Related PR on the apps side, to make slcan work after the "bitrate no
longer brings interface up" change:
https://github.com/apache/nuttx-apps/pull/3059
While testing this, I think I have discovered a small mistake on my
previous, Nuttx-side PR, which slipped by me and by revision: "ret"
might be
Hi Peter, that is the same flow I was thinking of.
I will create a PR affecting all the existing drivers.
Thanks,
Carlos
On Fri, Apr 11, 2025 at 1:42 PM Peter van der Perk
wrote:
>
> Hi Carlos,
>
> I think your concern is valid and that the current implementation of
> SIOCSCANBITRATE is a bu
Hi Carlos,
I think your concern is valid and that the current implementation of
SIOCSCANBITRATE is a bugged.
I think the solution would be to only allow SIOCSCANBITRATE when the interface
is down.
My proposal would be that SIOCSCANBITRATE checks if the interface is already up
and if that's th
