* Re: [PATCH v3 03/23] serial: omap: don't access the platform_device
From: Tony Lindgren @ 2012-08-24 19:07 UTC (permalink / raw)
To: Felipe Balbi
Cc: Kevin Hilman, Linux Kernel Mailing List, Santosh Shilimkar,
linux-serial, Sourav Poddar, Linux OMAP Mailing List,
Shubhrajyoti Datta, Linux ARM Kernel Mailing List, alan
In-Reply-To: <1345717983-18179-4-git-send-email-balbi@ti.com>
* Felipe Balbi <balbi@ti.com> [120823 03:37]:
> The driver doesn't need to know about its platform_device.
>
> Everything the driver needs can be done through the
> struct device pointer. In case we need to use the
> OMAP-specific PM function pointers, those can make
> sure to find the device's platform_device pointer
> so they can find the struct omap_device through
> pdev->archdata field.
>
> Tested-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH v3 01/23] serial: omap: define and use to_uart_omap_port()
From: Tony Lindgren @ 2012-08-24 19:07 UTC (permalink / raw)
To: Felipe Balbi
Cc: Kevin Hilman, Linux Kernel Mailing List, Santosh Shilimkar,
linux-serial, Sourav Poddar, Linux OMAP Mailing List,
Shubhrajyoti Datta, Linux ARM Kernel Mailing List, alan
In-Reply-To: <1345717983-18179-2-git-send-email-balbi@ti.com>
* Felipe Balbi <balbi@ti.com> [120823 03:37]:
> current code only works because struct uart_port
> is the first member on the uart_omap_port structure.
>
> If, for whatever reason, someone puts another
> member as the first of the structure, that cast
> won't work anymore. In order to be safe, let's use
> a container_of() which, for now, gets optimized into
> a cast anyway.
>
> Tested-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> arch/arm/plat-omap/include/plat/omap-serial.h | 2 ++
> drivers/tty/serial/omap-serial.c | 36 +++++++++++++--------------
> 2 files changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
> index 1a52725..f3b35d9 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -137,4 +137,6 @@ struct uart_omap_port {
> struct work_struct qos_work;
> };
>
> +#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port, port)))
> +
> #endif /* __OMAP_SERIAL_H__ */
For the arch/arm/*omap*/* parts:
Acked-by: Tony Lindgren <tony@atomide.com>
FYI, note that there are ARM SoC patches to move various header files to
live under include/linux/platform_data which may cause conflicts with these
changes.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH] tty: Added a CONFIG_TTY option to allow removal of TTY
From: Alan Cox @ 2012-08-24 17:12 UTC (permalink / raw)
To: Josh Triplett
Cc: Joe Millenbach, Greg Kroah-Hartman, linux-serial, linux-kernel,
team-fjord
In-Reply-To: <20120824170342.GA9794@jtriplet-mobl1>
> > The true cause I think is that serio/serport.c should depend on tty to be
> > built but the ps/2 mouse bits shouldn't.
>
> On the other hand, most people disabling CONFIG_TTY will be building an
> extreme embedded system, and on such a system a PS/2 mouse seems highly
> unlikely. Given that, perhaps the goal of removing dependencies on TTY
> could happen incrementally once CONFIG_TTY exists?
Fine by me
^ permalink raw reply
* Re: [PATCH] tty: Added a CONFIG_TTY option to allow removal of TTY
From: Josh Triplett @ 2012-08-24 17:03 UTC (permalink / raw)
To: Alan Cox
Cc: Joe Millenbach, Greg Kroah-Hartman, linux-serial, linux-kernel,
team-fjord
In-Reply-To: <20120824141537.63274081@pyramind.ukuu.org.uk>
On Fri, Aug 24, 2012 at 02:15:37PM +0100, Alan Cox wrote:
> On Thu, 23 Aug 2012 18:14:48 -0700
> Joe Millenbach <jmillenbach@gmail.com> wrote:
> > On Tue, Aug 21, 2012 at 6:20 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > >
> > > ...
> > >
> > > > config MOUSE_PS2
> > > > tristate "PS/2 mouse"
> > > > + depends on TTY
> > >
> > > It shouldn't. It would be good to understand why this occurs.
> >
> >
> > If I enable this config option, and turn off TTY I get the below errors.
> >
> > drivers/built-in.o: In function `serport_ldisc_read':
> > serport.c:(.text+0x1aace6): undefined reference to `tty_name'
> > serport.c:(.text+0x1aad57): undefined reference to `tty_name'
> > drivers/built-in.o: In function `serport_init':
> > serport.c:(.init.text+0x8478): undefined reference to `tty_register_ldisc'
> > drivers/built-in.o: In function `serport_exit':
> > serport.c:(.exit.text+0xb29): undefined reference to `tty_unregister_ldisc'
> >
> > All because MOUSE_PS2 depends on SERIO, just like a lot of entries I
> > blocked. I assume this means I should keep the dependency on TTY.
> > Unfortunately, I don't have time to dig deeper for the true cause of the
> > dependency right now.
>
> The true cause I think is that serio/serport.c should depend on tty to be
> built but the ps/2 mouse bits shouldn't.
On the other hand, most people disabling CONFIG_TTY will be building an
extreme embedded system, and on such a system a PS/2 mouse seems highly
unlikely. Given that, perhaps the goal of removing dependencies on TTY
could happen incrementally once CONFIG_TTY exists?
- Josh Triplett
^ permalink raw reply
* Re: [PATCH] tty: Added a CONFIG_TTY option to allow removal of TTY
From: Alan Cox @ 2012-08-24 13:15 UTC (permalink / raw)
To: Joe Millenbach
Cc: Greg Kroah-Hartman, linux-serial, linux-kernel, Josh Triplett,
team-fjord
In-Reply-To: <CADwDc1BgCM9AA4T3mUxfOGNaNoYwERP-x4y2ZS4mAhfF-K_qzA@mail.gmail.com>
On Thu, 23 Aug 2012 18:14:48 -0700
Joe Millenbach <jmillenbach@gmail.com> wrote:
> ---------- Forwarded message ----------
> From: Joe Millenbach <jmillenbach@gmail.com>
> Date: Thu, Aug 23, 2012 at 5:56 PM
> Subject: Re: [PATCH] tty: Added a CONFIG_TTY option to allow removal of TTY
> To: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Alan Cox
> <alan@linux.intel.com>, linux-serial@vger.kernel.org,
> linux-kernel@vger.kernel.org, Josh Triplett <josh@joshtriplett.org>,
> team-fjord@googlegroups.com
>
>
> On Tue, Aug 21, 2012 at 6:20 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >
> > ...
> >
> > > config MOUSE_PS2
> > > tristate "PS/2 mouse"
> > > + depends on TTY
> >
> > It shouldn't. It would be good to understand why this occurs.
>
>
> If I enable this config option, and turn off TTY I get the below errors.
>
> drivers/built-in.o: In function `serport_ldisc_read':
> serport.c:(.text+0x1aace6): undefined reference to `tty_name'
> serport.c:(.text+0x1aad57): undefined reference to `tty_name'
> drivers/built-in.o: In function `serport_init':
> serport.c:(.init.text+0x8478): undefined reference to `tty_register_ldisc'
> drivers/built-in.o: In function `serport_exit':
> serport.c:(.exit.text+0xb29): undefined reference to `tty_unregister_ldisc'
>
> All because MOUSE_PS2 depends on SERIO, just like a lot of entries I
> blocked. I assume this means I should keep the dependency on TTY.
> Unfortunately, I don't have time to dig deeper for the true cause of the
> dependency right now.
The true cause I think is that serio/serport.c should depend on tty to be
built but the ps/2 mouse bits shouldn't.
Alan
^ permalink raw reply
* Re: [PATCH v3 00/23] OMAP UART patches
From: Felipe Balbi @ 2012-08-24 10:40 UTC (permalink / raw)
To: Felipe Balbi
Cc: alan, Tony Lindgren, Kevin Hilman, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List, linux-serial,
Linux Kernel Mailing List, Santosh Shilimkar, Shubhrajyoti Datta,
Sourav Poddar, Greg KH
In-Reply-To: <1345717983-18179-1-git-send-email-balbi@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3024 bytes --]
Forgot to Cc greg initially, my bad
On Thu, Aug 23, 2012 at 01:32:40PM +0300, Felipe Balbi wrote:
> Hi guys,
>
> here's v3 and hopefully final version of this series. A whole bunch of new
> patches added but the good thing is that now I had another engineer's help to
> test, so he's got his Tested-by in all patches.
>
> Changes since v2:
> . Added a bunch of new patches
> . Fixed a problem where we would always return IRQ_NONE even though we
> handled IRQ
>
> Changes since v1:
> . improved commit log on patch 9/13 (formerly 10/13)
> . removed patch 2/13
> . added a new patch switching from spin_lock_irqsave() to spin_lock and
> spin_unlock_irqrestore to spin_unlock
>
> Alan, if you prefer in pull request form, here it is:
>
> The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92:
>
> Linux 3.6-rc2 (2012-08-16 14:51:24 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git uart
>
> for you to fetch changes up to a29230f14d8466c9b8c25171715378bf52189453:
>
> serial: omap: enable RX and TX FIFO usage (2012-08-23 09:25:16 +0300)
>
> ----------------------------------------------------------------
> Felipe Balbi (20):
> serial: omap: define and use to_uart_omap_port()
> serial: omap: define helpers for pdata function pointers
> serial: omap: don't access the platform_device
> serial: omap: drop DMA support
> serial: add OMAP-specific defines
> serial: omap: simplify IRQ handling
> serial: omap: refactor receive_chars() into rdi/rlsi handlers
> serial: omap: move THRE check to transmit_chars()
> serial: omap: stick to put_autosuspend
> serial: omap: set dev->drvdata before enabling pm_runtime
> serial: omap: drop unnecessary check from remove
> serial: omap: make sure to suspend device before remove
> serial: omap: don't save IRQ flags on hardirq
> serial: omap: optimization with section annotations
> serial: omap: drop "inline" from IRQ handler prototype
> serial: omap: implement set_wake
> serial: omap: make sure to put() on poll_get_char
> serial: omap: remove unnecessary header and add a missing one
> serial: omap: move uart_omap_port definition to C file
> serial: omap: enable RX and TX FIFO usage
>
> Ruchika Kharwar (2):
> serial: omap: fix sequence of pm_runtime_* calls.
> serial: omap: unlock the port lock
>
> Vikram Pandita (1):
> serial: omap: fix software flow control
>
> arch/arm/mach-omap2/serial.c | 15 +-
> arch/arm/plat-omap/include/plat/omap-serial.h | 47 +-
> drivers/tty/serial/omap-serial.c | 808 ++++++++++----------------
> include/linux/serial_reg.h | 4 +
> 4 files changed, 330 insertions(+), 544 deletions(-)
>
> --
> 1.7.12.rc3
>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
From: Tony Prisk @ 2012-08-24 7:18 UTC (permalink / raw)
To: Alexey Charkov
Cc: a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
FlorianSchandinat-Mmb7MZpHnFY@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
vt8500-wm8505-linux-kernel-/JYPxA39Uh5TLH3MbocFFw,
swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CABjd4Yxxf5XDc6gs0WABZgF3SOd89J7CfjsU9uitOg4qpQ4WEQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 2012-08-24 at 09:54 +0400, Alexey Charkov wrote:
> 2012/8/24 Tony Prisk <linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>:
> > On Fri, 2012-08-24 at 05:40 +0000, Arnd Bergmann wrote:
> >> On Thursday 23 August 2012, Tony Prisk wrote:
> >> > I was about to say that if Mike has any issues with the driver that I
> >> > can fix the patch conflict at the same time, but I just realised that
> >> > its more work than I originally thought :)
> >> >
> >> > I was going to move the arch-vt8500 part of the clocks patch back into
> >> > the clocks patch - but that will just move the issue from arm-soc to
> >> > clocks because Mike's branch won't have the arch-vt8500 patch so the
> >> > patch will fail.
> >>
> >> But that's ok, because without the arch-v8500 part, nothing uses
> >> the vt8500-clock driver, so nothing breaks. You can introduce broken
> >> code in the meantime as long as it's impossible to enable and it will
> >> work afterwards.
> >>
> >> Arnd
> >
> > You lost me a little bit there :)
> > If it stays as is now, the arch-vt8500 patch will introduce an
> > unresolved symbol.
> > If I move the clock code from the arch-vt8500 patch to the clock patch,
> > then the clock patch won't apply because it needs the arch-vt8500 patch
> > first and Mike won't have that patch, but it would be fine if both
> > patches went in via your tree.
>
> Why don't you add a #define in the first patch that makes your
> to-be-unresolved symbol a no-op and then drop it within the clock
> patch?
>
> Best,
> Alexey
>
Actually - that doesn't resolve the problem unless it all goes in via
the same tree still because the clock patch can only drop the #define if
the arch-vt8500 patch exists still - same as problem #2 I mentioned.
If the clock patch goes via Mikes tree he will need the arch-vt8500
patch as well - don't think it can be avoided.
Still easier to send the whole lot via arm-soc, then at least we can
resolve the patch conflicts without having to apply the patches twice.
Regards
Tony P
^ permalink raw reply
* Re: [RFC PATCH] tty: move the async flags from the serial code into the tty includes
From: Jiri Slaby @ 2012-08-24 7:17 UTC (permalink / raw)
To: Alan Cox; +Cc: greg, linux-serial, linux-kernel
In-Reply-To: <20120822144426.27149.93723.stgit@localhost.localdomain>
On 08/22/2012 04:44 PM, Alan Cox wrote:
> Jiri - this seem more sensible ?
I would be faster if you CCed me :).
> From: Alan Cox <alan@linux.intel.com>
>
> These are used with the tty_port flags which are tty generic so move the
> flags into a more sensible place. This then makes it possible to add
> helpers such as those suggested by Huang Shijie.
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
Acked-by: Jiri Slaby <jslaby@suse.cz>
> include/linux/Kbuild | 1 +
> include/linux/serial.h | 75 ++-----------------------------------------
> include/linux/tty.h | 1 +
> include/linux/tty_flags.h | 78 +++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 83 insertions(+), 72 deletions(-)
> create mode 100644 include/linux/tty_flags.h
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
From: Tony Prisk @ 2012-08-24 7:14 UTC (permalink / raw)
To: Alexey Charkov
Cc: a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
FlorianSchandinat-Mmb7MZpHnFY@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
vt8500-wm8505-linux-kernel-/JYPxA39Uh5TLH3MbocFFw,
swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CABjd4Yxxf5XDc6gs0WABZgF3SOd89J7CfjsU9uitOg4qpQ4WEQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 2012-08-24 at 09:54 +0400, Alexey Charkov wrote:
> 2012/8/24 Tony Prisk <linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>:
> > On Fri, 2012-08-24 at 05:40 +0000, Arnd Bergmann wrote:
> >> On Thursday 23 August 2012, Tony Prisk wrote:
> >> > I was about to say that if Mike has any issues with the driver that I
> >> > can fix the patch conflict at the same time, but I just realised that
> >> > its more work than I originally thought :)
> >> >
> >> > I was going to move the arch-vt8500 part of the clocks patch back into
> >> > the clocks patch - but that will just move the issue from arm-soc to
> >> > clocks because Mike's branch won't have the arch-vt8500 patch so the
> >> > patch will fail.
> >>
> >> But that's ok, because without the arch-v8500 part, nothing uses
> >> the vt8500-clock driver, so nothing breaks. You can introduce broken
> >> code in the meantime as long as it's impossible to enable and it will
> >> work afterwards.
> >>
> >> Arnd
> >
> > You lost me a little bit there :)
> > If it stays as is now, the arch-vt8500 patch will introduce an
> > unresolved symbol.
> > If I move the clock code from the arch-vt8500 patch to the clock patch,
> > then the clock patch won't apply because it needs the arch-vt8500 patch
> > first and Mike won't have that patch, but it would be fine if both
> > patches went in via your tree.
>
> Why don't you add a #define in the first patch that makes your
> to-be-unresolved symbol a no-op and then drop it within the clock
> patch?
>
> Best,
> Alexey
>
I knew we kept you around for a reason :)
Cheers,
Tony P
^ permalink raw reply
* Re: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
From: Alexey Charkov @ 2012-08-24 5:54 UTC (permalink / raw)
To: vt8500-wm8505-linux-kernel
Cc: a.zummo@towertech.it, linux-fbdev@vger.kernel.org,
linux@arm.linux.org.uk, linus.walleij@stericsson.com,
rtc-linux@googlegroups.com, FlorianSchandinat@gmx.de,
gregkh@linuxfoundation.org, devicetree-discuss@lists.ozlabs.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
rob.herring@calxeda.com, grant.likely@secretlab.ca,
rob@landley.net, linux-serial@vger.kernel.org, swarren@nvidia.com,
mturquette@ti.com
In-Reply-To: <1345787536.23177.3.camel@gitbox>
2012/8/24 Tony Prisk <linux@prisktech.co.nz>:
> On Fri, 2012-08-24 at 05:40 +0000, Arnd Bergmann wrote:
>> On Thursday 23 August 2012, Tony Prisk wrote:
>> > I was about to say that if Mike has any issues with the driver that I
>> > can fix the patch conflict at the same time, but I just realised that
>> > its more work than I originally thought :)
>> >
>> > I was going to move the arch-vt8500 part of the clocks patch back into
>> > the clocks patch - but that will just move the issue from arm-soc to
>> > clocks because Mike's branch won't have the arch-vt8500 patch so the
>> > patch will fail.
>>
>> But that's ok, because without the arch-v8500 part, nothing uses
>> the vt8500-clock driver, so nothing breaks. You can introduce broken
>> code in the meantime as long as it's impossible to enable and it will
>> work afterwards.
>>
>> Arnd
>
> You lost me a little bit there :)
> If it stays as is now, the arch-vt8500 patch will introduce an
> unresolved symbol.
> If I move the clock code from the arch-vt8500 patch to the clock patch,
> then the clock patch won't apply because it needs the arch-vt8500 patch
> first and Mike won't have that patch, but it would be fine if both
> patches went in via your tree.
Why don't you add a #define in the first patch that makes your
to-be-unresolved symbol a no-op and then drop it within the clock
patch?
Best,
Alexey
^ permalink raw reply
* Re: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
From: Tony Prisk @ 2012-08-24 5:52 UTC (permalink / raw)
To: vt8500-wm8505-linux-kernel-/JYPxA39Uh5TLH3MbocFFw
Cc: a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
FlorianSchandinat-Mmb7MZpHnFY@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
mturquette-l0cyMroinI0@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
alan
In-Reply-To: <201208240540.12316.arnd-r2nGTMty4D4@public.gmane.org>
On Fri, 2012-08-24 at 05:40 +0000, Arnd Bergmann wrote:
> On Thursday 23 August 2012, Tony Prisk wrote:
> > I was about to say that if Mike has any issues with the driver that I
> > can fix the patch conflict at the same time, but I just realised that
> > its more work than I originally thought :)
> >
> > I was going to move the arch-vt8500 part of the clocks patch back into
> > the clocks patch - but that will just move the issue from arm-soc to
> > clocks because Mike's branch won't have the arch-vt8500 patch so the
> > patch will fail.
>
> But that's ok, because without the arch-v8500 part, nothing uses
> the vt8500-clock driver, so nothing breaks. You can introduce broken
> code in the meantime as long as it's impossible to enable and it will
> work afterwards.
>
> Arnd
You lost me a little bit there :)
If it stays as is now, the arch-vt8500 patch will introduce an
unresolved symbol.
If I move the clock code from the arch-vt8500 patch to the clock patch,
then the clock patch won't apply because it needs the arch-vt8500 patch
first and Mike won't have that patch, but it would be fine if both
patches went in via your tree.
Or are you saying to apply the clock patch as is before the arch-vt8500
patch?
Tony P
^ permalink raw reply
* Re: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
From: Arnd Bergmann @ 2012-08-24 5:40 UTC (permalink / raw)
To: Tony Prisk
Cc: a.zummo@towertech.it, linux-fbdev@vger.kernel.org,
linux@arm.linux.org.uk, linus.walleij@stericsson.com,
rtc-linux@googlegroups.com, FlorianSchandinat@gmx.de,
gregkh@linuxfoundation.org, devicetree-discuss@lists.ozlabs.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
rob.herring@calxeda.com, grant.likely@secretlab.ca,
rob@landley.net, linux-serial@vger.kernel.org,
vt8500-wm8505-linux-kernel@googlegroups.com
In-Reply-To: <1345758702.2061.6.camel@gitbox>
On Thursday 23 August 2012, Tony Prisk wrote:
> I was about to say that if Mike has any issues with the driver that I
> can fix the patch conflict at the same time, but I just realised that
> its more work than I originally thought :)
>
> I was going to move the arch-vt8500 part of the clocks patch back into
> the clocks patch - but that will just move the issue from arm-soc to
> clocks because Mike's branch won't have the arch-vt8500 patch so the
> patch will fail.
But that's ok, because without the arch-v8500 part, nothing uses
the vt8500-clock driver, so nothing breaks. You can introduce broken
code in the meantime as long as it's impossible to enable and it will
work afterwards.
Arnd
^ permalink raw reply
* CAN I DEPOSIT 20,000,000.00 GBP INTO YOUR ACCOUNT
From: Mrs Margaret Edwards @ 2012-08-24 10:15 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 3 bytes --]
[-- Attachment #2: 20,000,000,00 GBP.rtf --]
[-- Type: application/msword, Size: 42321 bytes --]
^ permalink raw reply
* Fwd: [PATCH] tty: Added a CONFIG_TTY option to allow removal of TTY
From: Joe Millenbach @ 2012-08-24 1:14 UTC (permalink / raw)
To: Alan Cox
Cc: Greg Kroah-Hartman, linux-serial, linux-kernel, Josh Triplett,
team-fjord
In-Reply-To: <CADwDc1AvCvWbj8znN-1WbkZA9WYVAqaTkxi7+ENZfJ-qFNRAvw@mail.gmail.com>
---------- Forwarded message ----------
From: Joe Millenbach <jmillenbach@gmail.com>
Date: Thu, Aug 23, 2012 at 5:56 PM
Subject: Re: [PATCH] tty: Added a CONFIG_TTY option to allow removal of TTY
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Alan Cox
<alan@linux.intel.com>, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org, Josh Triplett <josh@joshtriplett.org>,
team-fjord@googlegroups.com
On Tue, Aug 21, 2012 at 6:20 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> ...
>
> > config MOUSE_PS2
> > tristate "PS/2 mouse"
> > + depends on TTY
>
> It shouldn't. It would be good to understand why this occurs.
If I enable this config option, and turn off TTY I get the below errors.
drivers/built-in.o: In function `serport_ldisc_read':
serport.c:(.text+0x1aace6): undefined reference to `tty_name'
serport.c:(.text+0x1aad57): undefined reference to `tty_name'
drivers/built-in.o: In function `serport_init':
serport.c:(.init.text+0x8478): undefined reference to `tty_register_ldisc'
drivers/built-in.o: In function `serport_exit':
serport.c:(.exit.text+0xb29): undefined reference to `tty_unregister_ldisc'
All because MOUSE_PS2 depends on SERIO, just like a lot of entries I
blocked. I assume this means I should keep the dependency on TTY.
Unfortunately, I don't have time to dig deeper for the true cause of the
dependency right now.
- Joe
* Resending message as I forgot to turn off HTML messaging in Gmail
(sorry), and I've heard SPAM blockers might eat HTML messages sent to
LKML people.
- Joe
^ permalink raw reply
* [PATCH] tty: use module_spi_driver
From: Devendra Naga @ 2012-08-23 22:04 UTC (permalink / raw)
To: linux-serial; +Cc: Alan Cox, Greg Kroah-Hartman, Devendra Naga
the driver's module init and exit functions can be replaced
with module_spi_driver as they do
only spi_register_driver and spi_unregister_driver in module's init and exit
paths.
Signed-off-by: Devendra Naga <develkernel412222@gmail.com>
---
drivers/tty/serial/max3100.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/tty/serial/max3100.c b/drivers/tty/serial/max3100.c
index b4902b9..46043c2 100644
--- a/drivers/tty/serial/max3100.c
+++ b/drivers/tty/serial/max3100.c
@@ -910,17 +910,7 @@ static struct spi_driver max3100_driver = {
.resume = max3100_resume,
};
-static int __init max3100_init(void)
-{
- return spi_register_driver(&max3100_driver);
-}
-module_init(max3100_init);
-
-static void __exit max3100_exit(void)
-{
- spi_unregister_driver(&max3100_driver);
-}
-module_exit(max3100_exit);
+module_spi_driver(max3100_driver);
MODULE_DESCRIPTION("MAX3100 driver");
MODULE_AUTHOR("Christian Pellegrin <chripell@evolware.org>");
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
From: Tony Prisk @ 2012-08-23 21:48 UTC (permalink / raw)
To: arnd-r2nGTMty4D4@public.gmane.org
Cc: a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org,
rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
FlorianSchandinat-Mmb7MZpHnFY@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
vt8500-wm8505-linux-kernel-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
mturquette-l0cyMroinI0@public.gmane.org
In-Reply-To: <201208231322.23077.arnd-r2nGTMty4D4@public.gmane.org>
On Thu, 2012-08-23 at 13:22 +0000, Arnd Bergmann wrote:
> On Thursday 23 August 2012, Tony Prisk wrote:
> > >On Thursday 23 August 2012, Tony Prisk wrote:
>
> >
> > Without the clock patch (9/9), the mach-vt8500 patch (6/9) won't compile
> > due to unresolved symbols.
> >
> > In arch/arm/mach-vt8500/vt8500.c - you will get an unresolved symbol
> > for 'vtwm_clk_init'
> >
> > Not sure if this matters, thought I should point it out.
> > Does it need to compile cleanly in your tree (which is what I would assume),
> > or just once its all combined in -next?
> > Does it matter that the usb patches are already in -next?
> >
> > I don't really understand the requirements around submitting to individual
> > trees and which (if any) of these points are actually issues.
>
> The rule is that each changeset should be free of regressions compared
> to the version before. So if you have a set of 7 patches in one branch
> that you want me to pick up, the result after applying those 7 patches
> should work, and each previous step should also work. You cannot for
> instance add a call to a function in one patch and then provide that
> function in the following patch.
>
> There are multiple ways to achieve this:
>
> * when you have dependencies, get everything merged through one
> maintainer tree, and get Acks for each patch that belongs to another
> maintainer.
>
> * submit a branch with the patches that other stuff depends on to
> both the subsystem maintainer who is responsible for it and to
> the subsystem maintainer who gets the other patches that are built
> on top of this branch. If you do this, you have to make sure that
> the first branch never gets rebased and that the second branch is
> not sent before the first one is upstream.
>
> * change the code so that no dependencies exist, e.g. by introducing
> a dummy implementation in one patch and the proper one in another.
> This can generate merge conflicts, but that's usually ok.
>
> Arnd
>
I was about to say that if Mike has any issues with the driver that I
can fix the patch conflict at the same time, but I just realised that
its more work than I originally thought :)
I was going to move the arch-vt8500 part of the clocks patch back into
the clocks patch - but that will just move the issue from arm-soc to
clocks because Mike's branch won't have the arch-vt8500 patch so the
patch will fail.
If Mike is OK with it once the clocks driver is reviewed, it will be a
lot easier for the whole lot to go in via arm-soc, otherwise I can try
figuring out how to get the arch-vt8500 patch to Mike first, and then
the clocks patch.
Regards
Tony Prisk
^ permalink raw reply
* Re: [PATCHv3 3/9] serial: vt8500: Add devicetree support for
From: Rob Landley @ 2012-08-23 21:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Tony Prisk, Alan Cox, Alessandro Zummo,
linux-fbdev, Russell King, Linus Walleij,
Florian Tobias Schandinat, Greg Kroah-Hartman, devicetree-discuss,
linux-usb, vt8500-wm8505-linux-kernel, linux-kernel, Rob Herring,
Grant Likely, linux-serial, rtc-linux, Stephen Warren, Alan Cox,
Mike Turquette
In-Reply-To: <201208220644.18059.arnd@arndb.de>
On 08/22/2012 01:44 AM, Arnd Bergmann wrote:
> On Wednesday 22 August 2012, Tony Prisk wrote:
>> The original patch was very simple, but I revisited it to fix other
>> issues and forgot to add the relevant comments.
>>
>> Port size is changed to fix a problem - WM8505 actually had 6 uart's
>> defined in platform data but the vt8500_ports variable was only 4.
>>
>> I have added devicetree port id support as well.
>
> If you do multiple things in one driver, you should normally send multiple
> patches as well, each with a description why that change is done.
> It may seem silly at first to send out a one-line patch next to a 100-line
> patch for the same file, but those cases are actually the ones where it's
> most important.
Think of us poor git-bisect monkeys who have no idea why something broke
but can (purely mechanically) figure out which commit did it. If it's a
patch that does three unrelated things, we're kinda stuck.
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
^ permalink raw reply
* Re: [rtc-linux] RE: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
From: Linus Walleij @ 2012-08-23 13:34 UTC (permalink / raw)
To: Tony Prisk
Cc: Arnd Bergmann,
vt8500-wm8505-linux-kernel-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
Russell King, Alessandro Zummo, Alan Cox, Greg Kroah-Hartman,
Florian Tobias Schandinat, Grant Likely, Rob Herring, Rob Landley,
Linus Walleij, Mike Turquette, Stephen Warren,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-serial>
In-Reply-To: <76F764B079F92A4E843589C893D0A022DAF68C14-A1+cU8XkcJSYgi1/3OOQJ8krCUz0bFs7@public.gmane.org>
On Thu, Aug 23, 2012 at 2:58 PM, Tony Prisk <linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org> wrote:
> Linus W has provided some feedback on the gpio driver - I missed the
> issues he raised the first time around so just waiting for him to take a look
> at v4 when he's got time.
Reviewed and OK:ed, looking good now.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [rtc-linux] [PATCHv4 8/9] arm: vt8500: gpio: Devicetree support for arch-vt8500
From: Linus Walleij @ 2012-08-23 13:31 UTC (permalink / raw)
To: Tony Prisk
Cc: vt8500-wm8505-linux-kernel-/JYPxA39Uh5TLH3MbocFFw, Russell King,
Alessandro Zummo, Alan Cox, Greg Kroah-Hartman,
Florian Tobias Schandinat, Arnd Bergmann, Grant Likely,
Rob Herring, Rob Landley, Linus Walleij, Mike Turquette,
Stephen Warren, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1345707346-9035-9-git-send-email-linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>
On Thu, Aug 23, 2012 at 9:35 AM, Tony Prisk <linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org> wrote:
> Converted the existing arch-vt8500 gpio to a platform_device.
> Added support for WM8505 and WM8650 GPIO controllers.
> Replaced existing readl/writel calls with _relaxed variants.
> Replaced existing unsigned variables with u32 to match register size.
>
> Signed-off-by: Tony Prisk <linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>
Sweet!
Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
From: Arnd Bergmann @ 2012-08-23 13:22 UTC (permalink / raw)
To: Tony Prisk
Cc: Alessandro Zummo,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King,
Linus Walleij, rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
Florian Tobias Schandinat, Greg Kroah-Hartman,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
vt8500-wm8505-linux-kernel-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
Stephen Warren, Mike Turquette,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <76F764B079F92A4E843589C893D0A022DAF68C14-A1+cU8XkcJSYgi1/3OOQJ8krCUz0bFs7@public.gmane.org>
On Thursday 23 August 2012, Tony Prisk wrote:
> >On Thursday 23 August 2012, Tony Prisk wrote:
>
> Without the clock patch (9/9), the mach-vt8500 patch (6/9) won't compile
> due to unresolved symbols.
>
> In arch/arm/mach-vt8500/vt8500.c - you will get an unresolved symbol
> for 'vtwm_clk_init'
>
> Not sure if this matters, thought I should point it out.
> Does it need to compile cleanly in your tree (which is what I would assume),
> or just once its all combined in -next?
> Does it matter that the usb patches are already in -next?
>
> I don't really understand the requirements around submitting to individual
> trees and which (if any) of these points are actually issues.
The rule is that each changeset should be free of regressions compared
to the version before. So if you have a set of 7 patches in one branch
that you want me to pick up, the result after applying those 7 patches
should work, and each previous step should also work. You cannot for
instance add a call to a function in one patch and then provide that
function in the following patch.
There are multiple ways to achieve this:
* when you have dependencies, get everything merged through one
maintainer tree, and get Acks for each patch that belongs to another
maintainer.
* submit a branch with the patches that other stuff depends on to
both the subsystem maintainer who is responsible for it and to
the subsystem maintainer who gets the other patches that are built
on top of this branch. If you do this, you have to make sure that
the first branch never gets rebased and that the second branch is
not sent before the first one is upstream.
* change the code so that no dependencies exist, e.g. by introducing
a dummy implementation in one patch and the proper one in another.
This can generate merge conflicts, but that's usually ok.
Arnd
^ permalink raw reply
* RE: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
From: Tony Prisk @ 2012-08-23 12:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alessandro Zummo,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Russell King,
Linus Walleij, rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
Florian Tobias Schandinat, Greg Kroah-Hartman,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
vt8500-wm8505-linux-kernel-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
Stephen Warren, Mike Turquette,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <201208231040.16702.arnd-r2nGTMty4D4@public.gmane.org>
>On Thursday 23 August 2012, Tony Prisk wrote:
>> Patchset based on Arnd's arm-soc/for-next branch.
>>
>>
>> Could I get this reviewed, hopefully for inclusion into v3.7.
>I can take them into the arm-soc tree if there are no new comments.
>For the last two patches, you need to get an Acked-by comment from the
>gpio and clk maintainers, respectively, or you should send them
>the patches for inclusion in those subsystem trees.
> Arnd
Linus W has provided some feedback on the gpio driver - I missed the
issues he raised the first time around so just waiting for him to take a look
at v4 when he's got time.
I haven't heard from Mike T in regards to the new clock code - He did
reply about the original patch (pre-devicetree) but I asked him to hold off
reviewing it because it was going to be rewritten.
EHCI/UHCI has gone to -next (on patchv2) via usb-next
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
There haven't been any changes to it in v3/v4.
GPIO going via another tree isn't really an issue if necessary.
Without the clock patch (9/9), the mach-vt8500 patch (6/9) won't compile
due to unresolved symbols.
In arch/arm/mach-vt8500/vt8500.c - you will get an unresolved symbol
for 'vtwm_clk_init'
Not sure if this matters, thought I should point it out.
Does it need to compile cleanly in your tree (which is what I would assume),
or just once its all combined in -next?
Does it matter that the usb patches are already in -next?
I don't really understand the requirements around submitting to individual
trees and which (if any) of these points are actually issues.
Regards
Tony Prisk
^ permalink raw reply
* Re: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***
From: Arnd Bergmann @ 2012-08-23 10:40 UTC (permalink / raw)
To: Tony Prisk
Cc: Alessandro Zummo, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
Russell King, Linus Walleij, rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
Florian Tobias Schandinat, Greg Kroah-Hartman,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
vt8500-wm8505-linux-kernel-/JYPxA39Uh5TLH3MbocFFw, Stephen Warren,
Mike Turquette, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Alan Cox
In-Reply-To: <1345707346-9035-1-git-send-email-linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>
On Thursday 23 August 2012, Tony Prisk wrote:
> Patchset based on Arnd's arm-soc/for-next branch.
>
>
> Could I get this reviewed, hopefully for inclusion into v3.7.
I can take them into the arm-soc tree if there are no new comments.
For the last two patches, you need to get an Acked-by comment from the
gpio and clk maintainers, respectively, or you should send them
the patches for inclusion in those subsystem trees.
Arnd
^ permalink raw reply
* [PATCH v3 22/23] serial: omap: move uart_omap_port definition to C file
From: Felipe Balbi @ 2012-08-23 10:33 UTC (permalink / raw)
To: alan
Cc: Tony Lindgren, Kevin Hilman, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List, linux-serial,
Linux Kernel Mailing List, Santosh Shilimkar, Shubhrajyoti Datta,
Sourav Poddar, Felipe Balbi
In-Reply-To: <1345717983-18179-1-git-send-email-balbi@ti.com>
nobody needs to access the uart_omap_port structure
other than omap-serial.c file. Let's move that
structure definition to the C source file in order
to prevent anyone from accessing our structure.
Tested-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/plat-omap/include/plat/omap-serial.h | 37 --------------------------
drivers/tty/serial/omap-serial.c | 38 +++++++++++++++++++++++++++
2 files changed, 38 insertions(+), 37 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index 12e6805..c266934 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -102,41 +102,4 @@ struct uart_omap_dma {
unsigned int rx_timeout;
};
-struct uart_omap_port {
- struct uart_port port;
- struct uart_omap_dma uart_dma;
- struct device *dev;
-
- unsigned char ier;
- unsigned char lcr;
- unsigned char mcr;
- unsigned char fcr;
- unsigned char efr;
- unsigned char dll;
- unsigned char dlh;
- unsigned char mdr1;
- unsigned char scr;
-
- int use_dma;
- /*
- * Some bits in registers are cleared on a read, so they must
- * be saved whenever the register is read but the bits will not
- * be immediately processed.
- */
- unsigned int lsr_break_flag;
- unsigned char msr_saved_flags;
- char name[20];
- unsigned long port_activity;
- u32 context_loss_cnt;
- u32 errata;
- u8 wakeups_enabled;
-
- struct pm_qos_request pm_qos_request;
- u32 latency;
- u32 calc_latency;
- struct work_struct qos_work;
-};
-
-#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port, port)))
-
#endif /* __OMAP_SERIAL_H__ */
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e5a56cb..0e5ffdf 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -69,6 +69,44 @@
#define OMAP_UART_MVR_MAJ_SHIFT 8
#define OMAP_UART_MVR_MIN_MASK 0x3f
+struct uart_omap_port {
+ struct uart_port port;
+ struct uart_omap_dma uart_dma;
+ struct device *dev;
+
+ unsigned char ier;
+ unsigned char lcr;
+ unsigned char mcr;
+ unsigned char fcr;
+ unsigned char efr;
+ unsigned char dll;
+ unsigned char dlh;
+ unsigned char mdr1;
+ unsigned char scr;
+
+ int use_dma;
+ /*
+ * Some bits in registers are cleared on a read, so they must
+ * be saved whenever the register is read but the bits will not
+ * be immediately processed.
+ */
+ unsigned int lsr_break_flag;
+ unsigned char msr_saved_flags;
+ char name[20];
+ unsigned long port_activity;
+ u32 context_loss_cnt;
+ u32 errata;
+ u8 wakeups_enabled;
+ unsigned int irq_pending:1;
+
+ struct pm_qos_request pm_qos_request;
+ u32 latency;
+ u32 calc_latency;
+ struct work_struct qos_work;
+};
+
+#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port, port)))
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
--
1.7.12.rc3
^ permalink raw reply related
* [PATCH v3 20/23] serial: omap: fix software flow control
From: Felipe Balbi @ 2012-08-23 10:33 UTC (permalink / raw)
To: alan
Cc: Tony Lindgren, Kevin Hilman, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List, linux-serial,
Linux Kernel Mailing List, Santosh Shilimkar, Shubhrajyoti Datta,
Sourav Poddar, Vikram Pandita, stable, Felipe Balbi
In-Reply-To: <1345717983-18179-1-git-send-email-balbi@ti.com>
From: Vikram Pandita <vikram.pandita@ti.com>
Software flow control register bits were not defined correctly.
Also clarify the IXON and IXOFF logic to reflect what userspace wants.
Cc: stable@vger.kernel.org
Tested-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/plat-omap/include/plat/omap-serial.h | 4 ++--
drivers/tty/serial/omap-serial.c | 12 ++++++------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index 743ac80..12e6805 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -42,10 +42,10 @@
#define OMAP_UART_WER_MOD_WKUP 0X7F
/* Enable XON/XOFF flow control on output */
-#define OMAP_UART_SW_TX 0x04
+#define OMAP_UART_SW_TX 0x8
/* Enable XON/XOFF flow control on input */
-#define OMAP_UART_SW_RX 0x04
+#define OMAP_UART_SW_RX 0x2
#define OMAP_UART_SYSC_RESET 0X07
#define OMAP_UART_TCR_TRIG 0X0F
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c3579c0..d49981d 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -606,19 +606,19 @@ serial_omap_configure_xonxoff
/*
* IXON Flag:
- * Enable XON/XOFF flow control on output.
- * Transmit XON1, XOFF1
+ * Flow control for OMAP.TX
+ * OMAP.RX should listen for XON/XOFF
*/
if (termios->c_iflag & IXON)
- up->efr |= OMAP_UART_SW_TX;
+ up->efr |= OMAP_UART_SW_RX;
/*
* IXOFF Flag:
- * Enable XON/XOFF flow control on input.
- * Receiver compares XON1, XOFF1.
+ * Flow control for OMAP.RX
+ * OMAP.TX should send XON/XOFF
*/
if (termios->c_iflag & IXOFF)
- up->efr |= OMAP_UART_SW_RX;
+ up->efr |= OMAP_UART_SW_TX;
serial_out(up, UART_EFR, up->efr | UART_EFR_ECB);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
--
1.7.12.rc3
^ permalink raw reply related
* [PATCH v3 16/23] serial: omap: drop "inline" from IRQ handler prototype
From: Felipe Balbi @ 2012-08-23 10:32 UTC (permalink / raw)
To: alan
Cc: Tony Lindgren, Kevin Hilman, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List, linux-serial,
Linux Kernel Mailing List, Santosh Shilimkar, Shubhrajyoti Datta,
Sourav Poddar, Felipe Balbi
In-Reply-To: <1345717983-18179-1-git-send-email-balbi@ti.com>
it makes no sense to mark our IRQ handler inline
since it's passed as a function pointer when
enabling the IRQ line.
Tested-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
drivers/tty/serial/omap-serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index bdfd019..ba22247 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -344,7 +344,7 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
* @irq: uart port irq number
* @dev_id: uart port info
*/
-static inline irqreturn_t serial_omap_irq(int irq, void *dev_id)
+static irqreturn_t serial_omap_irq(int irq, void *dev_id)
{
struct uart_omap_port *up = dev_id;
struct tty_struct *tty = up->port.state->port.tty;
--
1.7.12.rc3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox