linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Ludovic Barre <ludovic.barre@st.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linus.walleij@linaro.org,
	dwmw2@infradead.org, linux-mtd@lists.infradead.org,
	computersforpeace@gmail.com, Angus.Clark@st.com,
	DCG_UPD_stlinux_kernel@list.st.com, olivier.clergeaud@st.com
Subject: Re: [PATCH RESEND v4 01/37] mtd: st_spi_fsm: Allocate resources and register with MTD framework
Date: Thu, 23 Jan 2014 15:55:45 +0000	[thread overview]
Message-ID: <20140123155545.GH8586@lee--X1> (raw)
In-Reply-To: <52E12434.7030000@st.com>

> >+	fsm->region = devm_request_mem_region(&pdev->dev, res->start,
> >+					      resource_size(res), pdev->name);
> >+	if (!fsm->region) {
> >+		dev_err(&pdev->dev,
> >+			"Failed to reserve memory region [0x%08x-0x%08x]\n",
> >+			res->start, res->end);
> >+		return -EBUSY;
> >+	}
> >+
> >+	fsm->base = devm_ioremap_nocache(&pdev->dev,
> >+					 res->start, resource_size(res));
> >+	if (!fsm->base) {
> >+		dev_err(&pdev->dev, "Failed to ioremap [0x%08x]\n", res->start);
> >+		return -EINVAL;
> >+	}
> >+
> you can replace  "devm_request_mem_region" & "devm_ioremap_nocache"
> by "devm_ioremap_resource"

Yes, that looks entirely reasonable, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2014-01-23 15:55 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-23 10:30 [PATCH RESEND v4 00/37] mtd: st_spi_fsm: Add new driver Lee Jones
2014-01-23 10:30 ` [PATCH RESEND v4 01/37] mtd: st_spi_fsm: Allocate resources and register with MTD framework Lee Jones
2014-01-23 14:16   ` Ludovic Barre
2014-01-23 15:55     ` Lee Jones [this message]
2014-01-23 10:30 ` [PATCH RESEND v4 02/37] mtd: st_spi_fsm: Supply all register address and bit logic defines Lee Jones
2014-01-23 10:30 ` [PATCH RESEND v4 03/37] mtd: st_spi_fsm: Initialise and configure the FSM for normal working conditions Lee Jones
2014-01-23 10:30 ` [PATCH RESEND v4 04/37] mtd: st_spi_fsm: Supply framework for device requests Lee Jones
2014-01-23 10:30 ` [PATCH RESEND v4 05/37] mtd: st_spi_fsm: Supply a method to read from the FSM's FIFO Lee Jones
2014-01-23 10:30 ` [PATCH RESEND v4 06/37] mtd: st_spi_fsm: Supply defines for the possible flash command opcodes Lee Jones
2014-01-23 10:30 ` [PATCH RESEND v4 07/37] mtd: st_spi_fsm: Add support for JEDEC ID extraction Lee Jones
2014-01-23 10:30 ` [PATCH RESEND v4 08/37] mtd: devices: Provide header for shared OPCODEs and SFDP commands Lee Jones
2014-01-23 10:30 ` [PATCH RESEND v4 09/37] mtd: st_spi_fsm: Provide device look-up table Lee Jones
2014-01-23 10:30 ` [PATCH RESEND v4 10/37] mtd: st_spi_fsm: Dynamically setup flash device based on JEDEC ID Lee Jones
2014-01-23 10:30 ` [PATCH RESEND v4 11/37] mtd: st_spi_fsm: Search for preferred FSM message sequence configurations Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 12/37] mtd: st_spi_fsm: Fetch platform specific configurations Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 13/37] mtd: st_spi_fsm: Prepare the read/write FSM message sequence(s) Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 14/37] mtd: st_spi_fsm: Add device-tree binding documentation Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 15/37] mtd: st_spi_fsm: Fetch boot-device from mode pins Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 16/37] mtd: st_spi_fsm: Provide the erase one sector sequence Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 17/37] mtd: st_spi_fsm: Provide the sequence for enabling 32bit addressing mode Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 18/37] mtd: st_spi_fsm: Prepare read/write sequences according to configuration Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 19/37] mtd: st_spi_fsm: Add a check to if the chip can handle an SoC reset Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 20/37] mtd: st_spi_fsm: Provide a method to put the chip into 32bit addressing mode Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 21/37] mtd: st_spi_fsm: Update the flash Volatile Configuration Register Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 22/37] mtd: st_spi_fsm: Provide the default read/write configurations Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 23/37] mtd: st_spi_fsm: Supply the N25Qxxx specific read configurations Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 24/37] mtd: st_spi_fsm: Supply the N25Qxxx chip specific configuration call-back Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 25/37] mtd: st_spi_fsm: Prepare default sequences for read/write/erase Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 26/37] mtd: st_spi_fsm: Add the ability to read from a Serial Flash device Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 27/37] mtd: st_spi_fsm: Write to Flash via the FSM FIFO Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 28/37] mtd: st_spi_fsm: Supply a busy wait for post-write status Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 29/37] mtd: st_spi_fsm: Add the ability to write to a Serial Flash device Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 30/37] mtd: st_spi_fsm: Erase partly or as a whole " Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 31/37] mtd: st_spi_fsm: Add the ability to read the FSM's status Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 32/37] mtd: st_spi_fsm: Add the ability to write to FSM's status register Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 33/37] mtd: st_spi_fsm: Supply the MX25xxx chip specific configuration call-back Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 34/37] mtd: st_spi_fsm: Supply the S25FLxxx " Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 35/37] mtd: st_spi_fsm: Supply the W25Qxxx " Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 36/37] mtd: st_spi_fsm: Move runtime configurable msg sequences into device's struct Lee Jones
2014-01-23 10:31 ` [PATCH RESEND v4 37/37] ARM: STi: Add support for the FSM Serial Flash Controller Lee Jones
2014-02-11 15:00 ` [PATCH RESEND v4 00/37] mtd: st_spi_fsm: Add new driver Angus Clark
2014-02-14 10:46   ` Lee Jones

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=20140123155545.GH8586@lee--X1 \
    --to=lee.jones@linaro.org \
    --cc=Angus.Clark@st.com \
    --cc=DCG_UPD_stlinux_kernel@list.st.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ludovic.barre@st.com \
    --cc=olivier.clergeaud@st.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).