All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@mvista.com>
To: Greg KH <gregkh@suse.de>
Cc: Patrick Pannuto <ppannuto@codeaurora.org>,
	dbrownell@users.sourceforge.net, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, sboyd@codeaurora.org
Subject: Re: [PATCH] usb: gadget: #include device.h in gadget.h
Date: Thu, 08 Jul 2010 13:03:27 +0400	[thread overview]
Message-ID: <4C35945F.9050502@ru.mvista.com> (raw)
In-Reply-To: <20100708033420.GA24135@suse.de>

Hello.

Greg KH wrote:

>> gadget.h uses structures defined in device.h, it must include it. In
>> most cases, gadget.h is preceded by linux/platform_device.h, but if
>> you are grouping headers sanely, device.h may not be pulled in until
>> *after* gadget (e.g. mach/msm_device.h), thus gadget.h should not
>> rely on something else #including device.h

    As well as a number of other headers. I have postaed a patch addressing 
the missing #include's already.

>> include/linux/usb/gadget.h:488: error: field 'dev' has incomplete type

> Why not just provide an "empty" prototype for whatever is needed.

    Empty prototype of what, 'struct device'? Have you looked at the code at all?

struct usb_gadget {
	/* readonly to gadget driver */
	const struct usb_gadget_ops	*ops;
	struct usb_ep			*ep0;
	struct list_head		ep_list;	/* of usb_ep */
	enum usb_device_speed		speed;
	unsigned			is_dualspeed:1;
	unsigned			is_otg:1;
	unsigned			is_a_peripheral:1;
	unsigned			b_hnp_enable:1;
	unsigned			a_hnp_support:1;
	unsigned			a_alt_hnp_support:1;
	const char			*name;
	struct device			dev;
};

    How this is going to work with "empty prototype"?.

> Generally, having header files include header files is frowned apon, and
> a number of people have been working on slowly unwinding a lot of this
> type of mess that we currently have.

    IMO they could put their time to better use.

>> include/linux/usb/gadget.h: In function 'set_gadget_data':
>> include/linux/usb/gadget.h:492:
>> 	error: implicit declaration of function 'dev_set_drvdata'

> Ick, but then, this gets messier.

    What gets messier?

> How about just fixing up the .c file that the problem happens in, to
> include device.h first?  Is this an issue in the current tree somehow?

    In my opinion, this is just insane approach.

> thanks,
> greg k-h

WBR, Sergei


  reply	other threads:[~2010-07-08  9:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-08  0:47 [PATCH] usb: gadget: #include device.h in gadget.h Patrick Pannuto
2010-07-08  3:34 ` Greg KH
2010-07-08  9:03   ` Sergei Shtylyov [this message]
2010-07-08 15:13     ` Greg KH
2010-07-08 17:46       ` Sergei Shtylyov
2010-07-08 19:12 ` Sergei Shtylyov

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=4C35945F.9050502@ru.mvista.com \
    --to=sshtylyov@mvista.com \
    --cc=dbrownell@users.sourceforge.net \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=ppannuto@codeaurora.org \
    --cc=sboyd@codeaurora.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.