On 27/02/19 3:29 PM, Boris Brezillon wrote:
> On Wed, 27 Feb 2019 15:22:19 +0530
> Vignesh Raghavendra <vigneshr@xxxxxx> 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@xxxxxxxxxx>) 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
