Den 17.02.2020 13.11, skrev Mark Brown:
> On Sun, Feb 16, 2020 at 06:21:09PM +0100, Noralf Trønnes wrote:
>
>> Add support for regmap over USB for use with the Multifunction USB Device.
>> Two endpoints IN/OUT are used. Up to 255 regmaps are supported on one USB
>> interface. The register index width is always 32-bit, but the register
>> value can be 8, 16 or 32 bits wide. LZ4 compression is supported on bulk
>> transfers.
>> +static int regmap_usb_write(void *context, const void *data, size_t count)
>> +{
>> + struct regmap_usb_context *ctx = context;
>> + size_t val_len = count - sizeof(u32);
>> + void *val;
>> + int ret;
>> +
>> + /* buffer needs to be properly aligned for DMA use */
>> + val = kmemdup(data + sizeof(u32), val_len, GFP_KERNEL);
>> + if (!val)
>> + return -ENOMEM;
>> +
>> + ret = regmap_usb_gather_write(ctx, data, sizeof(u32), val, val_len);
>> + kfree(val);
>> +
>> + return ret;
>> +}
>
> This looks like you just don't support a straight write operation, if
> you need to do this emulation push it up the stack.
>
After going through the stack I realise that I have a problem.
What I have failed to fully comprehend is this regmap requirement:
if (val_len % map->format.val_bytes)
return -EINVAL;
There will be a spi and i2c driver down the line which will transfer
buffers of any size, and having to use 8-bit register values will not be
great.
When I started writing regmap-usb 6 months ago I didn't know where it
would take me. The result is now a Multifuntion USB device with an mfd
driver. So, no usage except for the children of the mfd device.
Dropping regmap won't lead to any increased code size to speak of, so
instead of trying to make regmap match my use case, I think I'll put
this code inside the mfd driver.
Oversights like this was one of the things I was hoping to unearth with
this RFC.
Thanks,
Noralf.
