Hello Cis van Mierlo,
THe BCC driver software package as the link below has TPL communication
based on DMA mode, whereas the Nuttx SPI drivers are in non DMA mode.
We tried extending this to TPL mode in Nuttx in Non DMA mode. But currently
we are facing some synchronization issues, want to get your
For what I see in Linux headers
#define O_ACCMODE 0003
#define O_RDONLY
#define O_WRONLY 0001
#define O_RDWR 0002
So 3 seems to be a reserved value and because O_RDONLY in Linux is defined
to 0 the 3 value from Linux is similar to 0 value in NuttX.
Regarding "Yes, for examp
Yes, for example if I want to set the serial device baud rate(TCSETS),
should I open it with O_WRONLY?
Linux has the concept of read IOCTLs and write IOCTLs as determined by
the IOCTL macros. My understanding is that you much provide O_RDONLY or
O_RDWR to use the read IOCTLs and O_WRONLY or
Yes, for example if I want to set the serial device baud rate(TCSETS),
should I open it with O_WRONLY?
On Sat, Apr 2, 2022 at 10:56 PM Gregory Nutt wrote:
> On 4/2/2022 7:03 AM, Xiang Xiao wrote:
> > Many functionality is accessed through ioctl callback, what permission is
> > needed before invo
On 4/2/2022 7:03 AM, Xiang Xiao wrote:
Many functionality is accessed through ioctl callback, what permission is
needed before invoking ioctl?
By permissions, you mean open mode? Per POSIX, O_WRONLY, O_RDONLY, or
O_RDWR is required on any success open call (or O_EXEC or O_SEARCH).
But I did
Here are a few examples of "broken" drivers:
- opamp_fops
- lcddev_fops
- g_pca9635pw_fileops
- g_foc_fops
- notectl_fops
- powerled_fops
- g_rptun_devops
- g_video_fops
The list is not complete. But since the "register_driver()" does not return
an error if both fops read and wr
Hi,
Here are a few examples of "broken" drivers:
- opamp_fops
- lcddev_fops
- g_pca9635pw_fileops
- g_foc_fops
- notectl_fops
- powerled_fops
- g_rptun_devops
- g_video_fops
The list is not complete. But since the "register_driver()" does not return
an error if both fops read and write po
> By doing so we can relax check in inode_checkflags() to:
>
> int inode_checkflags(FAR struct inode *inode, int oflags)
> {
> if ((oflags == 0) ||
> (oflags & O_WROK) != 0 && !inode->u.i_ops->write)
> {
> return -EACCES;
> }
> else
> {
> return OK;
> }
> }
>
>
Many functionality is accessed through ioctl callback, what permission is
needed before invoking ioctl?
On Sat, Apr 2, 2022 at 8:45 PM Gregory Nutt wrote:
> If I understand correctly we can add one single "dummy_read" implementation
> > for all drivers that do not supply the read method. This wi
If I understand correctly we can add one single "dummy_read" implementation
> for all drivers that do not supply the read method. This will ensure that
> O_RDOK is always supported if file permissions allow it.
>
There aren't any file permissions. The entire access is controlled by NULL
and non-N
Hi,
If I understand correctly we can add one single "dummy_read" implementation
for all drivers that do not supply the read method. This will ensure that
O_RDOK is always supported if file permissions allow it. By doing so we can
relax check in inode_checkflags() to:
int inode_checkflags(FAR stru
11 matches
Mail list logo
