All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Cc: dedekind1@gmail.com,
	Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-omap@vger.kernel.org, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
Date: Fri, 4 May 2012 10:11:25 -0700	[thread overview]
Message-ID: <20120504171125.GD5613@atomide.com> (raw)
In-Reply-To: <1520744.9xCxNUdyzk@acer>

Hi,

* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [120430 11:15]:
> Dnia czwartek, 26 kwietnia 2012 08:20:59 Artem Bityutskiy pisze:
> > On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote:
> > > Both drivers use separate subsets of registers that belong to the 
> OMAP1 
> > > MPU I/O device, but are used for controlling different sets of I/O 
> pins. 
> > > The NAND driver reads/writes the folowing registers:
> > > - OMAP_MPUIO_INPUT_LATCH,
> > > - OMAP_MPUIO_OUTPUT,
> > > - OMAP_MPUIO_IO_CNTL,
> > > while the keypad driver - the following:
> > > - OMAP_MPUIO_KBR_LATCH,
> > > - OMAP_MPUIO_KBC,
> > > - OMAP_MPUIO_KBD_MASKIT
> > > - OMAP_MPUIO_GPIO_DEBOUNCING.
> > > Both subsets are non-overlapping, and we rely on the drivers being 
> free 
> > > of bugs and doing their job correctly, not stepping on each others' 
> > > feet, I guess.
> > 
> > First of all, I think this information should be in the commit 
> message.
> > Also, some sort of comment in the driver code would be nice.
> > 
> > If locking the memory region is too coarse approach, the should have a
> > small separate omap-specific MPUIO subsystem which will be used by
> > drivers to access MPUIO?
> > 
> > Another question - should request_mem_region() be also removed from 
> the
> > omap-gpio driver then? I think it is more sensible to put a comment
> > there that it is sharing MPIO with other drivers,  instead of having 
> an
> > illusion of exclusive memory region ownership.
> > 
> > But this is up to the OMAP community - I can take this patch to my
> > l2-mtd tree if you get an ack from Tony or other OMAP guys.
> 
> Tony,
> Would I get your Ack for this fix if I extend the commit message as Artem 
> suggested? If not, what do you think should be a correct way to fix the 
> regression?

Well how about adding some exported functions to drivers/gpio/gpio_omap.c
like omap_mpuio_latch?

For the regression fix, if you guys want to do what Janusz is suggesting,
then assuming the patch description also contains some decent long term
plan to properly fix it:

Acked-by: Tony Lindgren <tony@atomide.com>

WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Cc: dedekind1@gmail.com, David Woodhouse <dwmw2@infradead.org>,
	Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-omap@vger.kernel.org
Subject: Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
Date: Fri, 4 May 2012 10:11:25 -0700	[thread overview]
Message-ID: <20120504171125.GD5613@atomide.com> (raw)
In-Reply-To: <1520744.9xCxNUdyzk@acer>

Hi,

* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [120430 11:15]:
> Dnia czwartek, 26 kwietnia 2012 08:20:59 Artem Bityutskiy pisze:
> > On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote:
> > > Both drivers use separate subsets of registers that belong to the 
> OMAP1 
> > > MPU I/O device, but are used for controlling different sets of I/O 
> pins. 
> > > The NAND driver reads/writes the folowing registers:
> > > - OMAP_MPUIO_INPUT_LATCH,
> > > - OMAP_MPUIO_OUTPUT,
> > > - OMAP_MPUIO_IO_CNTL,
> > > while the keypad driver - the following:
> > > - OMAP_MPUIO_KBR_LATCH,
> > > - OMAP_MPUIO_KBC,
> > > - OMAP_MPUIO_KBD_MASKIT
> > > - OMAP_MPUIO_GPIO_DEBOUNCING.
> > > Both subsets are non-overlapping, and we rely on the drivers being 
> free 
> > > of bugs and doing their job correctly, not stepping on each others' 
> > > feet, I guess.
> > 
> > First of all, I think this information should be in the commit 
> message.
> > Also, some sort of comment in the driver code would be nice.
> > 
> > If locking the memory region is too coarse approach, the should have a
> > small separate omap-specific MPUIO subsystem which will be used by
> > drivers to access MPUIO?
> > 
> > Another question - should request_mem_region() be also removed from 
> the
> > omap-gpio driver then? I think it is more sensible to put a comment
> > there that it is sharing MPIO with other drivers,  instead of having 
> an
> > illusion of exclusive memory region ownership.
> > 
> > But this is up to the OMAP community - I can take this patch to my
> > l2-mtd tree if you get an ack from Tony or other OMAP guys.
> 
> Tony,
> Would I get your Ack for this fix if I extend the commit message as Artem 
> suggested? If not, what do you think should be a correct way to fix the 
> regression?

Well how about adding some exported functions to drivers/gpio/gpio_omap.c
like omap_mpuio_latch?

For the regression fix, if you guys want to do what Janusz is suggesting,
then assuming the patch description also contains some decent long term
plan to properly fix it:

Acked-by: Tony Lindgren <tony@atomide.com>

  reply	other threads:[~2012-05-04 17:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-17 13:49 [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure Janusz Krzysztofik
2012-04-17 13:49 ` Janusz Krzysztofik
2012-04-17 13:49 ` Janusz Krzysztofik
2012-04-25 15:13 ` Artem Bityutskiy
2012-04-25 15:13   ` Artem Bityutskiy
2012-04-25 17:01   ` Janusz Krzysztofik
2012-04-25 17:01     ` Janusz Krzysztofik
2012-04-25 17:01     ` Janusz Krzysztofik
2012-04-26  5:20     ` Artem Bityutskiy
2012-04-26  5:20       ` Artem Bityutskiy
2012-04-30 18:09       ` Janusz Krzysztofik
2012-04-30 18:09         ` Janusz Krzysztofik
2012-05-04 17:11         ` Tony Lindgren [this message]
2012-05-04 17:11           ` Tony Lindgren
2012-05-04 19:23           ` Janusz Krzysztofik
2012-05-04 19:23             ` Janusz Krzysztofik
2012-05-07 20:51           ` [PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix " Janusz Krzysztofik
2012-05-07 20:51             ` Janusz Krzysztofik
2012-05-07 20:51             ` Janusz Krzysztofik
2012-05-08  7:03             ` Artem Bityutskiy
2012-05-08  7:03               ` Artem Bityutskiy
2012-05-08  7:03               ` Artem Bityutskiy
2012-05-08  7:11               ` Artem Bityutskiy
2012-05-08  7:11                 ` Artem Bityutskiy
2012-05-08  7:11                 ` Artem Bityutskiy
2012-05-08 18:46                 ` Janusz Krzysztofik
2012-05-08 18:46                   ` Janusz Krzysztofik
2012-05-08 18:46                   ` Janusz Krzysztofik

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=20120504171125.GD5613@atomide.com \
    --to=tony@atomide.com \
    --cc=Artem.Bityutskiy@linux.intel.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=jkrzyszt@tis.icnet.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.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.