On Fri, Nov 11, 2022 at 06:48:21AM +, Miod Vallat wrote:
> > This actually breaks my machine. malloc() is saying allocation too
> > large. OF_getproplen will return -1 on that. Is it possible that
> > len is treated as uint64_t as it is an int and sizeof is effectively
> > uint64_t?
>
>
> This actually breaks my machine. malloc() is saying allocation too
> large. OF_getproplen will return -1 on that. Is it possible that
> len is treated as uint64_t as it is an int and sizeof is effectively
> uint64_t?
Ah, yes; size_t is unsigned and wider than int on 64-bit platforms,
On Mon, Jul 04, 2022 at 06:47:33PM +, Miod Vallat wrote:
> When the fdt does not provide a list of brightness states, pwmbl(4)
> builds a 256 state ramp (i.e. state[i] = i with 0 <= i < 256).
>
> The following diff keeps that behaviour, but gets rid of the malloc
> call for that ramp, since
When the fdt does not provide a list of brightness states, pwmbl(4)
builds a 256 state ramp (i.e. state[i] = i with 0 <= i < 256).
The following diff keeps that behaviour, but gets rid of the malloc
call for that ramp, since the values are trivially known.
Compiles but not tested due to the lack
