linux-kernel - Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 4 Jul 2014 01:23:54 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Suman Anna <s-anna@...com>,
	Jassi Brar <jaswinder.singh@...aro.org>,
	Dave Gerlach <d-gerlach@...com>, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Jassi Brar <jassisinghbrar@...il.com>,
	Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices

* Pavel Machek <pavel@....cz> [140704 01:07]:
> Hi!
> 
> > > > >>>> The non-DT support has to be maintained for now to not break
> > > > >>>> OMAP3 legacy boot, and the legacy-style code will be cleaned
> > > > >>>> up once OMAP3 is also converted to DT-boot only.
> > > > >>>
> > > > >>>> @@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
> > > > >>>>  	return 0;
> > > > >>>>  }
> > > > >>>>  
> > > > >>>> +static const struct omap_mbox_device_data omap2_data = {
> > > > >>>> +	.num_users	= 4,
> > > > >>>> +	.num_fifos	= 6,
> > > > >>>> +	.intr_type	= MBOX_INTR_CFG_TYPE1,
> > > > >>>> +};
> > > > >>>> +
> > > > >>>> +static const struct omap_mbox_device_data omap3_data = {
> > > > >>>> +	.num_users	= 2,
> > > > >>>> +	.num_fifos	= 2,
> > > > >>>> +	.intr_type	= MBOX_INTR_CFG_TYPE1,
> > > > >>>> +};
> > > > >>>> +
> > > > >>>> +static const struct omap_mbox_device_data am335x_data = {
> > > > >>>> +	.num_users	= 4,
> > > > >>>> +	.num_fifos	= 8,
> > > > >>>> +	.intr_type	= MBOX_INTR_CFG_TYPE2,
> > > > >>>> +};
> > > > >>>
> 
> > > Aha, ok, then the intr_type should be derived from
> > > compatible-string. Or rather... you should have three
> > > compatible-strings for the three possibilities? (And then subtype,
> > > currently unused, in case there are more hw differences).
> > 
> > The compatible string can and should be separate for each revision
> > unless they are the same exacat hardware revision.
> 
> ACK.
> 
> > > > two are HW IP design parameters, so in general putting them in DT isn't
> > > > completely a bad idea, but I will wait to see if there are any further
> > > > comments on this from Tony or DT maintainers before I make changes.
> > > 
> > > Ok, right... I'd vote for putting them into DT.
> > 
> > I would avoid adding custom DT properties where possible and let the
> > driver just initialize the right data based on the compatible flag.
> 
> If these are HW IP design parameters, we can expect to see many
> different combinations. Yet we know ahead of time how to handle
> different parameters HW people select.
> 
> Thus IMO we should do it in the device tree.

Oh you mean from supporting new hardware with just .dts changes?
>From that point of view it makes sense to have them as DT properties,
so I'm fine with that.

Let's just try to use something that's generic like fifosize. No idea
how the property for num_fifos should be handled though as that
implies some knowledge in the driver which num_users have fifos?

So unless that can be described clearly in a DT property as well,
the binding might be still unusable for new hardware :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/