Re: [PATCH 28/57] media: Add ovxxxx_16bit_addr_reg_helpers.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 24, 2023 at 12:21:50PM +0100, Hans de Goede wrote:
> On 1/23/23 19:09, Andy Shevchenko wrote:
> > On Mon, Jan 23, 2023 at 01:51:36PM +0100, Hans de Goede wrote:
> >> The following drivers under drivers/media/i2c: ov08x40.c, ov13858.c,
> >> ov13b10.c, ov2680.c, ov2685.c, ov2740.c, ov4689.c, ov5670.c,
> >> ov5675.c, ov5695.c, ov8856.c, ov9282.c and ov9734.c,
> >>
> >> as well as various "atomisp" sensor drivers in drivers/staging, *all*
> >> use register access helpers with the following function prototypes:
> >>
> >> int ovxxxx_read_reg(struct ovxxxx_dev *sensor, u16 reg,
> >>                     unsigned int len, u32 *val);
> >>
> >> int ovxxxx_write_reg(struct ovxxxx_dev *sensor, u16 reg,
> >>                      unsigned int len, u32 val);
> >>
> >> To read/write registers on Omnivision OVxxxx image sensors wich expect
> >> a 16 bit register address in big-endian format and which have 1-3 byte
> >> wide registers, in big-endian format (for the higher width registers).
> >>
> >> Add a new ovxxxx_16bit_addr_reg_helpers.h header file with static inline
> >> versions of these register access helpers, so that this code duplication
> >> can be removed.

...

> >> +	msgs[1].buf = &data_buf[4 - len];
> > 
> > This trick I don't like. Can we have like other driver have it, i.e. switch
> > case for the possible length and explicit usage of the endian conversion
> > calls?
> 
> This new header (which is intended to eventually be used in many other
> ovXXXX drivers too) is modeled after the reg access helpers
> in drivers/media/i2c/ov*.c
> 
> And those do use be16 for the addr_buf in some cases, so I'm fine
> with changing that. But non of them do a switch-case on len,
> instead they all use similar tricks as this code (which was
> copied from drivers/media/i2c/ov2680.c) does.
> 
> So I would prefer to keep this as is, so that the new
> ovxxxx_16bit_addr_reg_helpers.h code is more like the code which
> it intends to replace.

Yes, this is rather for the followup improvements when we have all drivers use
these helpers.

But under "other drivers" I meant more or less IIO ones where similar
(to what I suggest) approach is being used.

-- 
With Best Regards,
Andy Shevchenko






[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux