The code there is already doing the right thing, as it uses value & 0xff, value & 0xff00, which already ensures the expected endiannes. So, it doesn't make any sense to touch the order depending on the CPU endiannes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> --- drivers/media/test-drivers/vidtv/vidtv_s302m.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/drivers/media/test-drivers/vidtv/vidtv_s302m.c b/drivers/media/test-drivers/vidtv/vidtv_s302m.c index 5ae2ede951eb..1bab2e231a55 100644 --- a/drivers/media/test-drivers/vidtv/vidtv_s302m.c +++ b/drivers/media/test-drivers/vidtv/vidtv_s302m.c @@ -352,14 +352,6 @@ static u32 vidtv_s302m_write_frame(struct vidtv_encoder *e, f.data[3] = (sample & 0x0FF0) >> 4; f.data[4] = (sample & 0xF000) >> 12; - #ifdef __LITTLE_ENDIAN - f.data[0] = reverse[f.data[0]]; - f.data[1] = reverse[f.data[1]]; - f.data[2] = reverse[f.data[2]]; - f.data[3] = reverse[f.data[3]]; - f.data[4] = reverse[f.data[4]]; - #endif - nbytes += vidtv_memcpy(e->encoder_buf, e->encoder_buf_offset, VIDTV_S302M_BUF_SZ, -- 2.26.2
