Is it somehow possible to say to kernel user in probe function that when parsing from device tree such entry:
reg = <0 0xffff0000 0 0x4>;
red-names = "some_name";
inform user that he can set in device tree only 32 bits of address?
probe(
....
struct resource *res;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "some_name");
if(res!)
return -EINVAL;
if(res->start > 0xFFFFFFFF) //this doesn't make sense
{
//pr_error("%s, only max 32 bits are supported\n", __func__);
return -EINVAL;
}
start variable in struct resource is type of resource_size_t.
On 32 bit arch this type is u32 and on 64 bit arch it is 64. Nevertheless on each architecture I want my driver supports only 32 bits.
I wonder if driver has to be such perfect and robust for everything user set in device tree or just information in kernel driver doc would be enough that user cannot set more than 32 bits.
On Fri, Apr 3, 2020 at 2:39 PM Tomek The Messenger <tomekthemessenger@xxxxxxxxx> wrote:
ok, for me strange was this ranges[0] declaration. I found other way to get to know mmio regmap size, just to remember pointer to struct resource* in private data in probe when parsing from device tree reg=<address, size>On Thu, Apr 2, 2020 at 2:15 PM Greg KH <greg@xxxxxxxxx> wrote:On Thu, Apr 02, 2020 at 01:48:23PM +0200, Tomek The Messenger wrote:
> Hi
> Let's see how it looks:
> https://github.com/u-boot/u-boot/blob/master/include/regmap.h
>
> I first time ever see such thing like this:
> struct regmap_range {
> ulong start;
> ulong size;
> };
> struct regmap {
> enum regmap_endianness_t endianness;
> int range_count;
> struct regmap_range ranges[0];
> };
>
> How I can get access to variable ranges it if is 0 size? Who develops this
> one and who reviewed:)
It is very common and standard C coding style. It happens all the time
when you have a variable of unknown length at declaration time.
> Anyway If I have pointer to regmap can I check what is start variable in
> some other way?
What other way do you need to check it?
Why do you think the above code is incorrect? What do you think it
should look like?
thanks,
greg k-h
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
