linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Pawel Laszczak <pawell@cadence.com>
Cc: linux-usb@vger.kernel.org, Felipe Balbi <balbi@kernel.org>,
	linux-kernel@vger.kernel.org, ltyrala@cadence.com,
	adouglas@cadence.com
Subject: [05/31] usb: usbssp: Added first part of initialization sequence.
Date: Thu, 12 Jul 2018 08:27:14 +0200	[thread overview]
Message-ID: <20180712062714.GI20905@kroah.com> (raw)

On Thu, Jul 12, 2018 at 06:47:02AM +0100, Pawel Laszczak wrote:
> +/* USB 2.0 hardware LMP capability*/
> +#define USBSSP_HLC			(1 << 19)
> +#define USBSSP_BLC			(1 << 20)

Again, BIT() please.

> +int usbssp_handshake(void __iomem *ptr, u32 mask, u32 done, int usec)
> +{
> +	u32	result;

Some places you use tabs for the variable declarations, and some you do
not.  Pick a single style and stick to it please.

> +
> +	do {
> +		result = readl(ptr);
> +		if (result == ~(u32)0)	/* card removed */
> +			return -ENODEV;
> +		result &= mask;
> +		if (result == done)
> +			return 0;
> +		udelay(1);
> +		usec--;
> +	} while (usec > 0);
> +	return -ETIMEDOUT;

We don't have a built-in kernel function to do this type of thing
already?  That's sad.  Oh well...

> +int usbssp_init(struct usbssp_udc *usbssp_data)
> +{
> +	int retval = 0;
> +
> +	usbssp_dbg_trace(usbssp_data, trace_usbssp_dbg_init, "usbssp_init");
> +
> +	spin_lock_init(&usbssp_data->lock);
> +	spin_lock_init(&usbssp_data->irq_thread_lock);
> +
> +	//TODO: memory initialization
> +	//retval = usbssp_mem_init(usbssp_data, GFP_KERNEL);
> +
> +	usbssp_dbg_trace(usbssp_data, trace_usbssp_dbg_init,
> +			"Finished usbssp_init");

When your trace functions do nothing but say "entered a function", and
"exited a function", why even have them?  ftrace can provide that for
you already, no need to overload that on the tracing framework, right?

> +/*
> + * gadget-if.c file is part of gadget.c file and implements interface
> + * for gadget driver
> + */
> +#include "gadget-if.c"

Ugh, I know USB hcd drivers love to include .c files in the middle of
them, but do we have to continue that crazy practice in newer drivers?
Is it really necessary?

> +	/*
> +	 * Check the compiler generated sizes of structures that must be laid
> +	 * out in specific ways for hardware access.
> +	 */
> +	BUILD_BUG_ON(sizeof(struct usbssp_doorbell_array) != 2*32/8);
> +	BUILD_BUG_ON(sizeof(struct usbssp_slot_ctx) != 8*32/8);
> +	BUILD_BUG_ON(sizeof(struct usbssp_ep_ctx) != 8*32/8);
> +	/* usbssp_device has eight fields, and also
> +	 * embeds one usbssp_slot_ctx and 31 usbssp_ep_ctx
> +	 */
> +	BUILD_BUG_ON(sizeof(struct usbssp_stream_ctx) != 4*32/8);
> +	BUILD_BUG_ON(sizeof(union usbssp_trb) != 4*32/8);
> +	BUILD_BUG_ON(sizeof(struct usbssp_erst_entry) != 4*32/8);
> +	BUILD_BUG_ON(sizeof(struct usbssp_cap_regs) != 8*32/8);
> +	BUILD_BUG_ON(sizeof(struct usbssp_intr_reg) != 8*32/8);
> +	/* usbssp_run_regs has eight fields and embeds 128 usbssp_intr_regs */
> +	BUILD_BUG_ON(sizeof(struct usbssp_run_regs) != (8+8*128)*32/8);

I love hard-coded numbers as much as the next person, but really?  Is
this necessary now that you have the code up and working properly?


I've stopped reviewing this series here.

thanks,

greg k-h
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2018-07-12  6:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-12  6:27 Greg Kroah-Hartman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-08-06 12:03 [05/31] usb: usbssp: Added first part of initialization sequence Pawel Laszczak
2018-08-06 10:33 Roger Quadros
2018-08-06  8:57 Pawel Laszczak
2018-08-03 10:17 Roger Quadros
2018-07-19 17:57 Pawel Laszczak
2018-07-12  9:47 Pawel Laszczak
2018-07-12  9:09 Greg Kroah-Hartman
2018-07-12  9:03 Pawel Laszczak
2018-07-12  5:47 Pawel Laszczak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180712062714.GI20905@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=adouglas@cadence.com \
    --cc=balbi@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=ltyrala@cadence.com \
    --cc=pawell@cadence.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).