Hi Marcel/Johan,
On Mar 6, 2015, at 7:49 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Ben,
>
>>>> On Tue, Mar 03, 2015, Kim, Ben Young Tae wrote:
>>>> This fixes the following sparse warning:
>>>>
>>>> drivers/bluetooth/btusb.c:2677:11: warning: incorrect type in initializer (different base types)
>>>> drivers/bluetooth/btusb.c:2677:11: expected restricted __le32 [usertype] rom_version
>>>> drivers/bluetooth/btusb.c:2677:11: got int
>>>> drivers/bluetooth/btusb.c:2678:11: warning: incorrect type in initializer (different base types)
>>>> drivers/bluetooth/btusb.c:2678:11: expected restricted __le32 [usertype] rom_version
>>>> drivers/bluetooth/btusb.c:2678:11: got int
>>>> drivers/bluetooth/btusb.c:2679:11: warning: incorrect type in initializer (different base types)
>>>> drivers/bluetooth/btusb.c:2679:11: expected restricted __le32 [usertype] rom_version
>>>> drivers/bluetooth/btusb.c:2679:11: got int
>>>> drivers/bluetooth/btusb.c:2680:11: warning: incorrect type in initializer (different base types)
>>>> drivers/bluetooth/btusb.c:2680:11: expected restricted __le32 [usertype] rom_version
>>>> drivers/bluetooth/btusb.c:2680:11: got int
>>>> drivers/bluetooth/btusb.c:2681:11: warning: incorrect type in initializer (different base types)
>>>> drivers/bluetooth/btusb.c:2681:11: expected restricted __le32 [usertype] rom_version
>>>> drivers/bluetooth/btusb.c:2681:11: got int
>>>> drivers/bluetooth/btusb.c:2805:17: warning: restricted __le16 degrades to integer
>>>> drivers/bluetooth/btusb.c:2805:37: warning: restricted __le32 degrades to integer
>>>> drivers/bluetooth/btusb.c:2806:17: warning: restricted __le16 degrades to integer
>>>> drivers/bluetooth/btusb.c:2806:39: warning: restricted __le32 degrades to integer
>>>>
>>>> Signed-off-by: Ben Young Tae Kim <ytkim@xxxxxxxxxxxxxxxx>
>>>> ---
>>>> drivers/bluetooth/btusb.c | 14 +++++++-------
>>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>>>> index 0833054..f65cd44 100644
>>>> --- a/drivers/bluetooth/btusb.c
>>>> +++ b/drivers/bluetooth/btusb.c
>>>> @@ -2674,11 +2674,11 @@ struct qca_device_info {
>>>> };
>>>>
>>>> static const struct qca_device_info qca_devices_table[] = {
>>>> - { 0x00000100, 20, 4, 10 }, /* Rome 1.0 */
>>>> - { 0x00000101, 20, 4, 10 }, /* Rome 1.1 */
>>>> - { 0x00000201, 28, 4, 18 }, /* Rome 2.1 */
>>>> - { 0x00000300, 28, 4, 18 }, /* Rome 3.0 */
>>>> - { 0x00000302, 28, 4, 18 }, /* Rome 3.2 */
>>>> + { cpu_to_le32(0x00000100), 20, 4, 10 }, /* Rome 1.0 */
>>>> + { cpu_to_le32(0x00000101), 20, 4, 10 }, /* Rome 1.1 */
>>>> + { cpu_to_le32(0x00000201), 28, 4, 18 }, /* Rome 2.1 */
>>>> + { cpu_to_le32(0x00000300), 28, 4, 18 }, /* Rome 3.0 */
>>>> + { cpu_to_le32(0x00000302), 28, 4, 18 }, /* Rome 3.2 */
>>>> };
>>>
>>> Since "struct qca_device_info" doesn't describe raw protocol data I
>>> don't think it should contain protocol endianness values, i.e. the
>>> rom_version member should be u32 instead of __le32.
>>>
>>
>> The rom_version will be coming from chipset when we ask chip version to soc at the first time and we are comparing to this during initialization. I think this should be _le32 type.
>
> I made a mistake in the review actually that I only now realized it. And this means that you really have not tested anything on big-endian architectures or just got lucky with the current values.
>
> So lets keep qca_device_info in host endian. It is a host data structure. It is not a wire data structure.
>
> This is actually the broken one:
>
> if (rver->rom_version != ver->rom_version ||
> rver->patch_version <= ver->patch_version) {
>
> You are now comparing little-endian values. That works all fine on a little-endian system, but on a big-endian system the <= comparison might not give you the result you are hoping for. So this all needs to be done with host endian values.
>
> Move qca_device_info to host endian and then go through the code and then do the little-endian transformation of data from the the hardware. You can easily check with spares (C=2) if you are doing this correctly.
>
Does host endian mean to use u32/u8 type instead of __le or __be? If yes, I’ll work on this and send you the patch soon after verifying it with C=2 option.
> Regards
>
> Marcel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks
— Ben Kim--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
