On Tue, Dec 12, 2017 at 1:45 PM, Mauro Carvalho Chehab
<mchehab@xxxxxxxxxx> wrote:
> Em Tue, 12 Dec 2017 03:42:32 -0800
> Joe Perches <joe@xxxxxxxxxxx> escreveu:
>
>> > I actually thought about marking them 'const' here before sending
>> > (without noticing the changelog text) and then ran into what must
>> > have led me to drop the 'const' originally: tuner_i2c_xfer_send()
>> > takes a non-const pointer. This can be fixed but it requires
>> > an ugly cast:
>>
>> Casting away const is always a horrible hack.
>>
>> Until it could be changed, my preference would
>> be to update the changelog and perhaps add to
>> the changelog the reason why it can not be const
>> as detailed below.
>>
>> ie: xfer_send and xfer_xend_recv both take a
>> non-const unsigned char *
Ok.
> Perhaps, on a separate changeset, we could change I2C routines to
> accept const unsigned char pointers. This is unrelated to tda8290
> KASAN fixes. So, it should go via I2C tree, and, once accepted
> there, we can change V4L2 drivers (and other drivers) accordingly.
I don't see how that would work unfortunately. i2c_msg contains
a pointer to the data, and that is used for both input and output,
including arrays like
struct i2c_msg msgs[] = {
{
.addr = dvo->slave_addr,
.flags = 0,
.len = 1,
.buf = &addr,
},
{
.addr = dvo->slave_addr,
.flags = I2C_M_RD,
.len = 1,
.buf = val,
}
};
that have one constant output pointer and one non-constant
input pointer. We could add an anonymous union for 'buf'
to make that two separate pointers, but that's barely any
better than the cast, and it would break the named initializers
in the example above, at least on older compilers. Adding
a second pointer to i2c_msg would add a bit of bloat and
also require tree-wide changes or ugly hacks.
Arnd
