linux-kernel - RE: [PATCH v2 1/4] usb: cdns2: Device side header file for CDNS2 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BYAPR07MB538177517C763C5FFA969ED1DD639@BYAPR07MB5381.namprd07.prod.outlook.com>
Date:   Thu, 20 Apr 2023 09:50:14 +0000
From:   Pawel Laszczak <pawell@...ence.com>
To:     Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "Daisy.Barrera@...iusxm.com" <Daisy.Barrera@...iusxm.com>,
        "Cliff.Holden@...iusxm.com" <Cliff.Holden@...iusxm.com>,
        Tony Lindgren <tony@...mide.com>,
        Jean Delvare <jdelvare@...e.de>,
        "neal_liu@...eedtech.com" <neal_liu@...eedtech.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        "egtvedt@...fundet.no" <egtvedt@...fundet.no>,
        Biju Das <biju.das.jz@...renesas.com>,
        "herve.codina@...tlin.com" <herve.codina@...tlin.com>
Subject: RE: [PATCH v2 1/4] usb: cdns2: Device side header file for CDNS2
 driver

>
>On Thu, Apr 20, 2023, at 11:00, Pawel Laszczak wrote:
>> Patch defines macros, registers and structures used by Device side
>> driver.
>>
>> Signed-off-by: Pawel Laszczak <pawell@...ence.com>
>
>> +struct cdns2_ep0_regs {
>> +	__u8 rxbc;
>> +	__u8 txbc;
>> +	__u8 cs;
>> +	__u8 reserved1[4];
>> +	__u8 fifo;
>> +	__le32 reserved2[94];
>> +	__u8 setupdat[8];
>> +	__u8 reserved4[88];
>> +	__u8 maxpack;
>> +} __packed;
>
>> +struct cdns2_epx_base {
>> +	__le16 rxbc;
>> +	__u8 rxcon;
>> +	__u8 rxcs;
>> +	__le16 txbc;
>> +	__u8 txcon;
>> +	__u8 txcs;
>> +} __packed;
>
>> +struct cdns2_epx_regs {
>> +	__le32 reserved[2];
>> +	struct cdns2_epx_base ep[15];
>> +	__u8 reserved2[290];
>> +	__u8 endprst;
>> +	__u8 reserved3[41];
>> +	__le16 isoautoarm;
>> +	__u8 reserved4[10];
>> +	__le16 isodctrl;
>> +	__le16 reserved5;
>> +	__le16 isoautodump;
>> +	__le32 reserved6;
>> +	__le16 rxmaxpack[15];
>> +	__le32 reserved7[65];
>> +	__le32 rxstaddr[15];
>> +	__u8 reserved8[4];
>> +	__le32 txstaddr[15];
>> +	__u8 reserved9[98];
>> +	__le16 txmaxpack[15];
>> +} __packed;
>
>Register structures should generally not be __packed, otherwise any multi-
>byte registers will be accessed as individual bytes on architectures that have
>no unaligned load/store.
>
>If you are worried about struct packing on OABI arm, you can mark it as both
>__packed and __aligned(4). Most drivers just avoid the problem by not
>defining these as structures but instead use macros with register offsets.
>

Extra __alligned(4) is ok for me. 
>From performance point of view the accessed as individual byte is not a problem.
All these registers are used mainly during initialization and enumeration. 

While transfer, when the performance is important driver use DMA registers which are
32 bits and are aligned.

Thanks,
Pawel