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: Wed, 27 Feb 2019 15:42:27 +0530 From: Vignesh Raghavendra <vigneshr@...com> To: Boris Brezillon <bbrezillon@...nel.org> CC: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>, David Woodhouse <dwmw2@...radead.org>, Brian Norris <computersforpeace@...il.com>, Marek Vasut <marek.vasut@...il.com>, Richard Weinberger <richard@....at>, Rob Herring <robh+dt@...nel.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>, "tudor.ambarus@...rochip.com" <tudor.ambarus@...rochip.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Nori, Sekhar" <nsekhar@...com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Miquel Raynal <miquel.raynal@...tlin.com> Subject: Re: [RFC PATCH 3/5] mtd: Add support for Hyperbus memory devices On 27/02/19 3:29 PM, Boris Brezillon wrote: > On Wed, 27 Feb 2019 15:22:19 +0530 > Vignesh Raghavendra <vigneshr@...com> wrote: > >> On 26/02/19 11:46 PM, Sergei Shtylyov wrote: >>> On 02/19/2019 09:36 AM, Vignesh R (by way of Boris Brezillon <bbrezillon@...nel.org>) wrote: >>> > [...] >>>> + */ >>>> + >>>> +struct hb_device { >>>> + struct map_info map; >>>> + struct device *dev; >>>> + struct device_node *np; >>>> + struct mtd_info *mtd; >>>> + struct hb_ops *ops; >>>> + enum hb_memtype memtype; >>>> + bool needs_calib; >>>> + bool registered; >>>> +}; >>>> + >>>> +/** >>>> + * struct hb_ops - struct representing custom Hyperbus operations >>>> + * @read16: read 16 bit of data, usually from register/ID-CFI space >>>> + * @write16: write 16 bit of data, usually to register/ID-CFI space >>>> + * copy_from: copy data from flash memory >>>> + * copy_to: copy data to flash_memory >>>> + */ >>>> + >>>> +struct hb_ops { >>>> + u16 (*read16)(struct hb_device *hbdev, unsigned long addr); >>>> + void (*write16)(struct hb_device *hbdev, unsigned long addr, u16 val); >>>> + >>>> + void (*copy_from)(struct hb_device *hbdev, void *to, >>>> + unsigned long from, ssize_t len); >>>> + void (*copy_to)(struct hb_device *dev, unsigned long to, >>>> + const void *from, ssize_t len); >>> >>> ... else these methods won't fly if you need to "massage" the controller >>> registers inside them... >>> >> >> If accessing controller register is the only need, wouldn't a private >> data pointer within struct hb_device be sufficient to hold pointer to >> controller specific struct? >> >> struct hb_device { >> ... >> void *priv; /* points to controller's private data */ >> }; >> >> >> Or do you see a need for separate structure for the HyperBus controller? > > Sorry to chime in. Just want to share my experience here: properly > splitting the controller/device representation is always a good thing. > When it's not done from the beginning and people start to add their own > controller drivers as if it was a flash device driver it becomes messy > pretty quickly and people add hacks to support that (look at the raw > NAND framework if you need a proof). So, I'd recommend having this > separation now, even if the onle controllers we support have a 1:1 > relationship between HB controller and HB device. > >> Alright, will separate controller and slave representation. Thanks for the feedback! -- Regards Vignesh
Powered by blists - more mailing lists