All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, Alan Cox <alan@linux.intel.com>,
	devicetree-discuss@lists.ozlabs.org,
	Greg Kroah-Hartman <gregkh@suse.de>,
	kernel@pengutronix.de, linux-serial@vger.kernel.org
Subject: Re: [PATCH] serial/efm32: add new driver
Date: Fri, 23 Dec 2011 10:35:22 +0000	[thread overview]
Message-ID: <201112231035.23215.arnd@arndb.de> (raw)
In-Reply-To: <1324561092-1945-1-git-send-email-u.kleine-koenig@pengutronix.de>

On Thursday 22 December 2011, Uwe Kleine-König wrote:

> @@ -0,0 +1,14 @@
> +* Energymicro efm32 UART
> +
> +Required properties:
> +- compatible : Should be "efm32,usart"
> +- reg : Address and length of the register set
> +- interrupts : Should contain uart interrupt
> +
> +Example:
> +
> +uart@0x4000c400 {
> +	compatible = "efm32,usart";
> +	reg = <0x4000c400 0x400>;
> +	interrupts = <15>;
> +};

Do you know if the usart was actually designed by energymicro or licensed
from another party? If it is a licensed part, it would be better to
list the "compatible" value under the company name that made it.

I would suggest that you also support the "clock-frequency" and/or
"current-speed" properties that are defined for serial ports, see the
of_serial driver.

> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 925a1e5..cfeb0f3 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1610,4 +1610,14 @@ config SERIAL_XILINX_PS_UART_CONSOLE
>  	help
>  	  Enable a Xilinx PS UART port to be the system console.
>  
> +config SERIAL_EFM32_USART
> +	bool "EFM32 USART port."
> +	depends on ARCH_EFM32
> +	select SERIAL_CORE

Why not tristate? If it's not a console, you should be able to use
it as a module.

I would generally prefer not to make the driver depend on the
platform, so we can get better compile time coverage. I think a better
set of dependencies would be

	depends on HAVE_CLK
	depends on OF
	default ARCH_EFM32

> +static void efm32_usart_write32(struct efm32_usart_port *efm_port,
> +		u32 value, unsigned offset)
> +{
> +	__raw_writel(value, efm_port->port.membase + offset);
> +}
> +
> +static u32 efm32_usart_read32(struct efm32_usart_port *efm_port,
> +		unsigned offset)
> +{
> +	return __raw_readl(efm_port->port.membase + offset);
> +}

Please use writel_relaxed() instead of __raw_writel().

> +static int __devinit efm32_usart_probe(struct platform_device *pdev)
> +{
> +	struct efm32_usart_port *efm_port;
> +	struct resource *res;
> +	int ret;
> +
> +	efm_port = kzalloc(sizeof(*efm_port), GFP_KERNEL);
> +	if (!efm_port) {
> +		dev_dbg(&pdev->dev, "failed to allocate private data\n");
> +		return -ENOMEM;
> +	}
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res) {
> +		ret = -ENODEV;
> +		dev_dbg(&pdev->dev, "failed to determine base address\n");
> +		goto err_get_base;
> +	}
> +
> +	if (resource_size(res) < 60) {
> +		ret = -EINVAL;
> +		dev_dbg(&pdev->dev, "memory resource too small\n");
> +		goto err_too_small;
> +	}

of_iomap() would be simpler here. I think you can leave out the assignment to 
mapbase, and go straight to membase here.

checking the resource size should not be necessary, because that would imply
having an invalid device tree, which you don't have to check at run time.

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

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, Alan Cox <alan@linux.intel.com>,
	devicetree-discuss@lists.ozlabs.org,
	"Greg Kroah-Hartman" <gregkh@suse.de>,
	kernel@pengutronix.de, linux-serial@vger.kernel.org
Subject: Re: [PATCH] serial/efm32: add new driver
Date: Fri, 23 Dec 2011 10:35:22 +0000	[thread overview]
Message-ID: <201112231035.23215.arnd@arndb.de> (raw)
In-Reply-To: <1324561092-1945-1-git-send-email-u.kleine-koenig@pengutronix.de>

On Thursday 22 December 2011, Uwe Kleine-König wrote:

> @@ -0,0 +1,14 @@
> +* Energymicro efm32 UART
> +
> +Required properties:
> +- compatible : Should be "efm32,usart"
> +- reg : Address and length of the register set
> +- interrupts : Should contain uart interrupt
> +
> +Example:
> +
> +uart@0x4000c400 {
> +	compatible = "efm32,usart";
> +	reg = <0x4000c400 0x400>;
> +	interrupts = <15>;
> +};

Do you know if the usart was actually designed by energymicro or licensed
from another party? If it is a licensed part, it would be better to
list the "compatible" value under the company name that made it.

I would suggest that you also support the "clock-frequency" and/or
"current-speed" properties that are defined for serial ports, see the
of_serial driver.

> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 925a1e5..cfeb0f3 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1610,4 +1610,14 @@ config SERIAL_XILINX_PS_UART_CONSOLE
>  	help
>  	  Enable a Xilinx PS UART port to be the system console.
>  
> +config SERIAL_EFM32_USART
> +	bool "EFM32 USART port."
> +	depends on ARCH_EFM32
> +	select SERIAL_CORE

Why not tristate? If it's not a console, you should be able to use
it as a module.

I would generally prefer not to make the driver depend on the
platform, so we can get better compile time coverage. I think a better
set of dependencies would be

	depends on HAVE_CLK
	depends on OF
	default ARCH_EFM32

> +static void efm32_usart_write32(struct efm32_usart_port *efm_port,
> +		u32 value, unsigned offset)
> +{
> +	__raw_writel(value, efm_port->port.membase + offset);
> +}
> +
> +static u32 efm32_usart_read32(struct efm32_usart_port *efm_port,
> +		unsigned offset)
> +{
> +	return __raw_readl(efm_port->port.membase + offset);
> +}

Please use writel_relaxed() instead of __raw_writel().

> +static int __devinit efm32_usart_probe(struct platform_device *pdev)
> +{
> +	struct efm32_usart_port *efm_port;
> +	struct resource *res;
> +	int ret;
> +
> +	efm_port = kzalloc(sizeof(*efm_port), GFP_KERNEL);
> +	if (!efm_port) {
> +		dev_dbg(&pdev->dev, "failed to allocate private data\n");
> +		return -ENOMEM;
> +	}
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res) {
> +		ret = -ENODEV;
> +		dev_dbg(&pdev->dev, "failed to determine base address\n");
> +		goto err_get_base;
> +	}
> +
> +	if (resource_size(res) < 60) {
> +		ret = -EINVAL;
> +		dev_dbg(&pdev->dev, "memory resource too small\n");
> +		goto err_too_small;
> +	}

of_iomap() would be simpler here. I think you can leave out the assignment to 
mapbase, and go straight to membase here.

checking the resource size should not be necessary, because that would imply
having an invalid device tree, which you don't have to check at run time.

	Arnd

  reply	other threads:[~2011-12-23 10:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-21 15:05 [PATCH] serial/efm32: add new driver Uwe Kleine-König
2011-12-21 15:05 ` Uwe Kleine-König
2011-12-21 20:28 ` Alan Cox
2011-12-21 20:28   ` Alan Cox
2011-12-22  8:57   ` Uwe Kleine-König
     [not found]   ` <20111221202847.4ffeba10-Z/y2cZnRghHXmaaqVzeoHQ@public.gmane.org>
2011-12-22 13:38     ` Uwe Kleine-König
2011-12-22 13:38       ` Uwe Kleine-König
2011-12-23 10:35       ` Arnd Bergmann [this message]
2011-12-23 10:35         ` Arnd Bergmann
2011-12-23 20:44         ` Uwe Kleine-König
     [not found]           ` <20111223204428.GI24496-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-01-09  9:59             ` Kconfig option for compile time build coverage (Was: Re: [PATCH] serial/efm32: add new driver) Uwe Kleine-König
2012-01-09  9:59               ` Uwe Kleine-König
2012-01-25 16:16               ` Arnd Bergmann
2012-01-25 16:16                 ` Arnd Bergmann
2012-01-09 10:34           ` [PATCH] serial/efm32: add new driver Uwe Kleine-König
2012-01-25 16:56             ` Arnd Bergmann
2012-01-25 16:56               ` Arnd Bergmann
     [not found]       ` <1324561092-1945-1-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-01-09 16:44         ` [PATCH v3] " Uwe Kleine-König
2012-01-09 16:44           ` Uwe Kleine-König
2012-01-24 22:05           ` Greg KH
2012-01-24 22:05             ` Greg KH
2012-01-25  8:05             ` [PATCH v4] " Uwe Kleine-König
2012-01-25  8:05               ` Uwe Kleine-König
2012-01-25  8:25               ` Joe Perches
2012-01-25  8:25                 ` Joe Perches
2012-01-25  8:41                 ` Uwe Kleine-König
2012-01-25 15:52               ` Greg KH
2012-01-25 18:36                 ` Uwe Kleine-König
2012-01-25 18:36                   ` Uwe Kleine-König

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=201112231035.23215.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=alan@linux.intel.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=gregkh@suse.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.