Hi KR, I think you acted correctly and probably you created this driver days or weeks before that discussion took place and this new rule was applied.
But since it was applied to someone, we need to stick to the rule, otherwise we will create more unfairness, misunderstanding and chaos. I think you understand this point. I was against that move (and removal) from (of) old char device sensors , but now I'm convinced that is the way to go. So we will need to learn more about it and as you said we need proper documentation about how to create proper uORB sensor drivers. At least for me they appear very different, some use threads, others don't, etc. Maybe a "skeleton.c" as exists for other drivers could be created to be used as a good example. BR, Alan On Thu, Dec 4, 2025 at 3:25 AM <[email protected]> wrote: > Hi, > > well, I looked back at the thread, but couldn't figure out where the > misunderstanding came from. Maybe you missed that I was - over the > course of the thread - talking about two different sensor drivers? (The > August one as a motivation to submit the TC74Ax driver and QMI8658 > driver as a likely cause of merge conflict for the TC74Ax in its current > form.) > > Anyway, to sum it up: I posted the TC74Ax driver knowing that it is > implemented using obsolete interface. I decided to submit it anyway a) > to show how was the TWI driver (the primary component of the series) > tested and b) because another non-uORB driver was merged in August. I > don't follow NuttX development that closely so I didn't know what the > current policy is - so I went with "the driver is already done - no hurt > in offering it even if it doesn't get merged in the end" approach. > > Other than that - I suggested PR #17405 to be closed because I didn't > expect anyone is going to be doing any further work on it. If someone > does, that's a different story of course. > > On 2025-12-03 12:38, Alan C. Assis wrote: > > Hi KR, > > > > I'm also confused, I understood that char device sensor shouldn't be > > merged > > anymore, see the discussion here: > > > > https://github.com/apache/nuttx/pull/17363 > > > > This PR was merged after requesting him to remove the char device > > sensor > > from his original commit. > > > > So, I think it isn't fair not to accept his QMI8658 char device sensor, > > but > > to accept your TC74 char device sensor. > > > > Matteo, I suggest we convert the TC74 sensor to uORB and not integrate > > it > > as a char device, to be coherent with what we did to Huang Qi. > > > > Tomek, since you are taking care of these patch sets, could you work on > > this conversion after you return from your delegation trip? > > If you need, I can help you with that. > > > > BR, > > > > Alan > > > > > > On Wed, Dec 3, 2025 at 7:28 AM <[email protected]> wrote: > > > >> Hi, > >> > >> just a bit of a clarification, I think there was a bit of > >> misunderstanding > >> > >> On 2025-12-02 21:05, Alan C. Assis wrote: > >> > Hi KR, > >> > > >> > The previous PR with QMI8658 sensor that was merged is uORB, the > >> > ordinary > >> > char device sensor was removed from the final PR. > >> > >> In my previous message, I was not advocating for merging this driver > >> in > >> its current form. When I said that another driver was merged, I meant > >> the one you're talking about, but only in the context of git merge > >> conflict. (Another driver was merged - changed Kconfig etc. - my > >> driver > >> is in conflict now.) I did not even know it had the char device > >> feature > >> before being merged, I don't follow the development that closely. > >> > >> Anyway, I think that PRs #17405 can be closed now. As suggested, I > >> won't > >> be spending time on the driver in its current form and I will not have > >> any time to rework it at least until the end of the year. Same for > >> #17406 which depends on #17405. > >> >
