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
| ||
|
Date: Mon, 13 Jan 2020 12:36:18 +0100 From: Arnd Bergmann <arnd@...db.de> To: Viresh Kumar <viresh.kumar@...aro.org> Cc: Sudeep Holla <sudeep.holla@....com>, Jassi Brar <jassisinghbrar@...il.com>, cristian.marussi@....com, peng.fan@....com, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH V2] firmware: arm_scmi: Make scmi core independent of transport type On Mon, Jan 13, 2020 at 7:42 AM Viresh Kumar <viresh.kumar@...aro.org> wrote: > On 10-01-20, 12:15, Arnd Bergmann wrote: > > On Fri, Jan 10, 2020 at 10:43 AM Viresh Kumar <viresh.kumar@...aro.org> wrote: > > > > Simply dropping the __iomem isn't much better, now you get other > > type mismatches. > > Right. So what exactly do you suggest I should do now? Drop __iomem > from the structure's payload field but keep all local variables and > function arguments with __iomem ? > > > +struct scmi_chan_info { > > > + void *payload; > > > + struct device *dev; > > > + struct scmi_handle *handle; > > > + void *transport_info; > > > +}; > > > > Maybe you can wrap the scmi_chan_info inside of another > > structure that contains the payload pointer, and use container_of > > to convert between them? > > We don't need to convert between the two of them, isn't it ? Are you > referring some other field here ? > > It's not obvious which parts of the structure should be shared and > > which are transport specific. > > All transport specific information is kept in the transport specific > structure which is saved here in the transport_info field. Is there > something else that isn't clear ? To answer all three, what I meant is that the payload pointer appears to be transport specific and should not be part of the common structure if there is generic way to access it. Arnd
Powered by blists - more mailing lists