[RESEND PATCH, v5 4/5] usb: Add MediaTek USB3 DRD Driver
Chunfeng Yun
chunfeng.yun at mediatek.com
Wed Aug 31 05:11:26 PDT 2016
On Tue, 2016-08-30 at 19:20 +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 26, 2016 at 05:38:27PM +0800, chunfeng yun wrote:
> > Hi,
> >
> > On Thu, 2016-08-25 at 10:32 +0200, Oliver Neukum wrote:
> > > On Thu, 2016-08-25 at 11:05 +0800, Chunfeng Yun wrote:
> > > > This patch adds support for the MediaTek USB3 controller
> > > > integrated into MT8173. It can be configured as Dual-Role
> > > > Device (DRD), Peripheral Only and Host Only (xHCI) modes.
> > > >
> > >
> > > > +/**
> > > > + * General Purpose Descriptor (GPD):
> > > > + * The format of TX GPD is a little different from RX one.
> > > > + * And the size of GPD is 16 bytes.
> > > > + *
> > > > + * @flag:
> > > > + * bit0: Hardware Own (HWO)
> > > > + * bit1: Buffer Descriptor Present (BDP), always 0, BD is not supported
> > > > + * bit2: Bypass (BPS), 1: HW skips this GPD if HWO = 1
> > > > + * bit7: Interrupt On Completion (IOC)
> > > > + * @chksum: This is used to validate the contents of this GPD;
> > > > + * If TXQ_CS_EN / RXQ_CS_EN bit is set, an interrupt is issued
> > > > + * when checksum validation fails;
> > > > + * Checksum value is calculated over the 16 bytes of the GPD by default;
> > > > + * @data_buf_len (RX ONLY): This value indicates the length of
> > > > + * the assigned data buffer
> > > > + * @next_gpd: Physical address of the next GPD
> > > > + * @buffer: Physical address of the data buffer
> > > > + * @buf_len:
> > > > + * (TX): This value indicates the length of the assigned data buffer
> > > > + * (RX): The total length of data received
> > > > + * @ext_len: reserved
> > > > + * @ext_flag:
> > > > + * bit5 (TX ONLY): Zero Length Packet (ZLP),
> > > > + */
> > > > +struct qmu_gpd {
> > > > + u8 flag;
> > > > + u8 chksum;
> > > > + u16 data_buf_len;
> > > > + u32 next_gpd;
> > > > + u32 buffer;
> > > > + u16 buf_len;
> > > > + u8 ext_len;
> > > > + u8 ext_flag;
> > > > +} __packed;
> > >
> > > It looks like this is shared with hardware in memory.
> > > But you leave the endianness of the bigger fields undeclared.
> > >
> > The driver only supports Little-Endian SoCs currently, because I have no
> > Big-Endian platform to test it.
>
> that's ok, you still have to mark the endian of the data and use it in
> that manner, you can't just not worry about it.
>
> Please fix up.
Ok, I will do it
thank you
>
> thanks,
>
> greg k-h
More information about the linux-arm-kernel
mailing list