All of lore.kernel.org
 help / color / mirror / Atom feed
From: andrew@lunn.ch (Andrew Lunn)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] phy-core: Don't allow building phy-core as a module
Date: Tue, 11 Feb 2014 17:42:05 +0100	[thread overview]
Message-ID: <20140211164205.GC24633@lunn.ch> (raw)
In-Reply-To: <1392134631-32030-1-git-send-email-hdegoede@redhat.com>

On Tue, Feb 11, 2014 at 05:03:51PM +0100, Hans de Goede wrote:
> include/phy/phy.h has stub code in there for when building without the
> phy-core enabled. This is useful for generic drivers such as ahci-platform,
> ehci-platoform and ohci-platform which have support for driving an optional
> phy passed to them through the devicetree.
> 
> Since on some boards this phy functionality is not needed, being able to
> disable the phy subsystem without needing a lot of #ifdef magic in the
> driver using it is quite useful.
> 
> However this breaks when the module using the phy subsystem is build-in and
> the phy-core is not, which leads to the build failing with missing symbol
> errors in the linking stage of the zImage.
> 
> Which leads to gems such as this being added to the Kconfig for achi_platform:
> 
> 	depends on GENERIC_PHY || !GENERIC_PHY
> 
> Rather then duplicating this code in a lot of places using the phy-core,
> I believe it is better to simply not allow the phy-core to be built as a
> module. The phy core is quite small and has no external dependencies, so
> always building it in when enabling it should not be an issue.

Hi Hans

I ran into the same problem with sata_mv. I ended up adding a select
GENERIC_PHY to force it to be built in.

So i agree with you to make it only built in.

Acked-by: Andrew Lunn <andrew@lunn.ch>

	  Andrew

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
To: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>,
	devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
	Maxime Ripard
	<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
Subject: Re: [PATCH] phy-core: Don't allow building phy-core as a module
Date: Tue, 11 Feb 2014 17:42:05 +0100	[thread overview]
Message-ID: <20140211164205.GC24633@lunn.ch> (raw)
In-Reply-To: <1392134631-32030-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Tue, Feb 11, 2014 at 05:03:51PM +0100, Hans de Goede wrote:
> include/phy/phy.h has stub code in there for when building without the
> phy-core enabled. This is useful for generic drivers such as ahci-platform,
> ehci-platoform and ohci-platform which have support for driving an optional
> phy passed to them through the devicetree.
> 
> Since on some boards this phy functionality is not needed, being able to
> disable the phy subsystem without needing a lot of #ifdef magic in the
> driver using it is quite useful.
> 
> However this breaks when the module using the phy subsystem is build-in and
> the phy-core is not, which leads to the build failing with missing symbol
> errors in the linking stage of the zImage.
> 
> Which leads to gems such as this being added to the Kconfig for achi_platform:
> 
> 	depends on GENERIC_PHY || !GENERIC_PHY
> 
> Rather then duplicating this code in a lot of places using the phy-core,
> I believe it is better to simply not allow the phy-core to be built as a
> module. The phy core is quite small and has no external dependencies, so
> always building it in when enabling it should not be an issue.

Hi Hans

I ran into the same problem with sata_mv. I ended up adding a select
GENERIC_PHY to force it to be built in.

So i agree with you to make it only built in.

Acked-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>

	  Andrew

  reply	other threads:[~2014-02-11 16:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-11 16:03 [PATCH] phy-core: Don't allow building phy-core as a module Hans de Goede
2014-02-11 16:03 ` Hans de Goede
2014-02-11 16:42 ` Andrew Lunn [this message]
2014-02-11 16:42   ` Andrew Lunn
2014-02-12  8:46 ` Roger Quadros
2014-02-12  8:46   ` Roger Quadros

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=20140211164205.GC24633@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=linux-arm-kernel@lists.infradead.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.