Re: [PATCH RFC 2/3] rust: Add bindings for device properties

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 29, 2024 at 11:05 PM Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Tue, Oct 29, 2024 at 2:35 PM Rob Herring <robh@xxxxxxxxxx> wrote:
> >
> > On Tue, Oct 29, 2024 at 1:57 PM Miguel Ojeda
> > <miguel.ojeda.sandonis@xxxxxxxxx> wrote:
> > >
> > > On Tue, Oct 29, 2024 at 7:48 PM Alice Ryhl <aliceryhl@xxxxxxxxxx> wrote:
> > > >
> > > > One option is to define a trait for integers:
> >
> > Yeah, but that doesn't feel like something I should do here. I imagine
> > other things might need the same thing. Perhaps the bindings for
> > readb/readw/readl for example. And essentially the crate:num already
> > has the trait I need. Shouldn't the kernel mirror that? I recall
> > seeing some topic of including crates in the kernel?
>
> Looking a bit closer at FromBytes, that's almost what I need. I'm not
> worried if it also includes usize and isize. However, since the trait
> also is provided for arrays/slices, the following happens to work:
>
> let prop: [i16; 4] = dev.property_read(c_str!("test,i16-array"))?;
>
> Which is a typo meant to be:
>
> let prop: [i16; 4] = dev.property_read_array(c_str!("test,i16-array"))?;
>
> And it doesn't really work. It reads all the data, but reads it as a
> u64 (DT data is BE), so the order is wrong.
>
> And now my dreams of "if it compiles, it works" are shattered. ;)

It sounds like FromBytes isn't the right way to go, then.

Alice





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux