On 17.05.22 09:42, Sean Young wrote:
> Oliver,
>
> On Tue, May 17, 2022 at 09:34:49AM +0200, Oliver Neukum wrote:
>> On 16.05.22 18:40, Sean Young wrote:
>>> On Mon, May 16, 2022 at 01:00:30PM +0200, Oliver Neukum wrote:
>>>> On 13.05.22 18:23, Sean Young wrote:
>>>> Hi!
>>>>> On Thu, May 12, 2022 at 03:03:21PM +0200, Oliver Neukum wrote:
>>>>>> No buffer can be embedded inside a descriptor, not even a simple be64.
>>>>>> Use a separate kmalloc()
>>>>> This patch needs a tiny change from be64_to_cpu() to be64_to_cpup(), I've
>>>>> tested that change with the hardware.
>>>> Needs? It is certainly not wrong and the subsequent logging will be in the
>>>> converted order, but need
>>> It certainly is wrong, and it doesn't compile without it, so yes it does
>>> need it. The kernel test robot also complained about.
>>>
>>>
>> Hi,
>>
>> sorry, it seems I forgot a "*". You are right.
> Thank you for your patches, they fix many important issues that I missed.
>
Hi,
sorry for being a bit obnoxious about this, but there is a slight issue.
This is the old code:
static void imon_ir_data(struct imon *imon)
{
struct ir_raw_event rawir = {};
u64 data = be64_to_cpu(imon->ir_buf);
u8 packet_no = data & 0xff;
int offset = 40;
int bit;
if (packet_no == 0xff)
return;
dev_dbg(imon->dev, "data: %*ph", 8, &imon->ir_buf);
The dev_dbg() logs the data as it is in the buffer. If you use
be64_to_cpup() instead of be64_to_cpu() you reverse
the buffer on a little endian CPU and hence the debug
output will be changed.
The actual driver code is unaffected, because the
buffer is never used again, so this is not a big deal.
The error is mine by changing the type of imon->ir_buf
But the fix is not quite the best.
Regards
Oliver
