Alan Cox | 1 Nov 12:42 2011
Picon

Re: [PATCH] UART: add CSR SiRFprimaII SoC on-chip uart drivers

> i am not sure whether i will make Linus confused if i send a new
> version at this moment. how about i send a seperate patch to fix this
> after the driver is applied?

That would be the best idea - its a trivial typo so doesn't really
matter much.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alan Cox | 1 Nov 13:18 2011
Picon

Re: [PATCH 02/14] ARM : SAMSUNG : Add RS485 support.

> +config SAMSUNG_HAS_RS485
> +	bool "Enable RS485 support for Samsung"
> +	depends on SERIAL_SAMSUNG && (MACH_CONDOR2440 ||
> MACH_CONDOR2416 || MACH_MINI2440)
> +	default y if (MACH_CONDOR2440 || MACH_CONDOR2416)
> +	default n if (MACH_MINI2440)

There really needs to be more ARM thinking about doing this sort of
stuff at runtime. If you can detect the board type at runtime then you
need to be moving towards kicking board specifics out of the depends,
and treating it as an "include support for this, if the board has it"
so you can move towards less build time only configuration.

> +/* FIXME */
> +	#if 0
> +	if (last_state != en) {
> +

So this doesn't look ready to submit either...

> +		if ((utrstat & S3C2410_UTRSTAT_TXE) ? 1 : 0) {
> +			if (cfg->gpio_transmit_en > -1) {
> +
> gpio_set_value(cfg->gpio_transmit_en, 0);
> +			}

Lots of excess brackets (see CodingStyle) - removing a few of the
excess ones would make it easier to read later.

The later bits become a real mess of ifdefs - much not your fault, the
(Continue reading)

Alan Cox | 1 Nov 13:55 2011
Picon

Re: [PATCH 1/2] pch_uart: Fix hw-flow control issue

On Thu, 27 Oct 2011 15:45:18 +0900
Tomoya MORINAGA <tomoya-linux <at> dsn.lapis-semi.com> wrote:

> Using hardware flow control,
> currently, register of the control-bit(AFE) is not set.
> This patch fixes the issue.
> 
> Signed-off-by: Tomoya MORINAGA <tomoya-linux <at> dsn.lapis-semi.com>

Acked-by: Alan Cox <alan <at> linux.intel.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alan Cox | 1 Nov 13:55 2011
Picon

Re: [PATCH 1/2] pch_uart: Support new device LAPIS Semiconductor ML7831 IOH

On Fri, 28 Oct 2011 09:38:49 +0900
Tomoya MORINAGA <tomoya-linux <at> dsn.lapis-semi.com> wrote:

> ML7831 is companion chip for Intel Atom E6xx series.
> 
> Signed-off-by: Tomoya MORINAGA <tomoya-linux <at> dsn.lapis-semi.com>

Acked-by: Alan Cox <alan <at> linux.intel.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alan Cox | 1 Nov 13:57 2011
Picon

Re: [PATCH 2/2] pch_uart: Delete modem status interrupt enable code

> (pch_uart device has auto hardware flow control function. So,
> pch_uart driver doesn't have to control modem status interrupt.)

This is true for flow control bits but not for incoming carrier detect ?

> This patch deletes the code.

> +	dev_info(priv->port.dev,
> +		"PCH UART : Modem status interrupt is not
> supported.\n"); }

dev_info seems wrong here. Does the user need to know this ?
Barry Song | 1 Nov 13:48 2011
Picon

Re: [PATCH] UART: add CSR SiRFprimaII SoC on-chip uart drivers

2011/11/1 Alan Cox <alan <at> linux.intel.com>:
>> i am not sure whether i will make Linus confused if i send a new
>> version at this moment. how about i send a seperate patch to fix this
>> after the driver is applied?
>
> That would be the best idea - its a trivial typo so doesn't really
> matter much.
ok, Alan.

Linus, have you gotten it? and can you apply it?
or do you want this to go through tty tree and merge it until next merge window?

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

Greg KH | 1 Nov 14:10 2011

Re: [PATCH] UART: add CSR SiRFprimaII SoC on-chip uart drivers

On Tue, Nov 01, 2011 at 08:48:29PM +0800, Barry Song wrote:
> 2011/11/1 Alan Cox <alan <at> linux.intel.com>:
> >> i am not sure whether i will make Linus confused if i send a new
> >> version at this moment. how about i send a seperate patch to fix this
> >> after the driver is applied?
> >
> > That would be the best idea - its a trivial typo so doesn't really
> > matter much.
> ok, Alan.
> 
> Linus, have you gotten it? and can you apply it?
> or do you want this to go through tty tree and merge it until next merge window?

That's probably the easiest thing to do, right?  Send it to me and I can
handle it.

thanks,

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

Barry Song | 1 Nov 14:28 2011
Picon

Re: [PATCH] UART: add CSR SiRFprimaII SoC on-chip uart drivers

2011/11/1 Greg KH <greg <at> kroah.com>:
> On Tue, Nov 01, 2011 at 08:48:29PM +0800, Barry Song wrote:
>> 2011/11/1 Alan Cox <alan <at> linux.intel.com>:
>> >> i am not sure whether i will make Linus confused if i send a new
>> >> version at this moment. how about i send a seperate patch to fix this
>> >> after the driver is applied?
>> >
>> > That would be the best idea - its a trivial typo so doesn't really
>> > matter much.
>> ok, Alan.
>>
>> Linus, have you gotten it? and can you apply it?
>> or do you want this to go through tty tree and merge it until next merge window?
>
> That's probably the easiest thing to do, right?  Send it to me and I can
> handle it.

Hi Greg, thanks! as i checked your tree, this patch should be able to
apply on your tree since you already have pinmux subsystem.
do i need to git send-email to you again for this?

>
> thanks,
>
> greg k-h
>

-barry
Greg KH | 1 Nov 14:40 2011

Re: [PATCH] UART: add CSR SiRFprimaII SoC on-chip uart drivers

On Tue, Nov 01, 2011 at 09:28:39PM +0800, Barry Song wrote:
> 2011/11/1 Greg KH <greg <at> kroah.com>:
> > On Tue, Nov 01, 2011 at 08:48:29PM +0800, Barry Song wrote:
> >> 2011/11/1 Alan Cox <alan <at> linux.intel.com>:
> >> >> i am not sure whether i will make Linus confused if i send a new
> >> >> version at this moment. how about i send a seperate patch to fix this
> >> >> after the driver is applied?
> >> >
> >> > That would be the best idea - its a trivial typo so doesn't really
> >> > matter much.
> >> ok, Alan.
> >>
> >> Linus, have you gotten it? and can you apply it?
> >> or do you want this to go through tty tree and merge it until next merge window?
> >
> > That's probably the easiest thing to do, right?  Send it to me and I can
> > handle it.
> 
> Hi Greg, thanks! as i checked your tree, this patch should be able to
> apply on your tree since you already have pinmux subsystem.
> do i need to git send-email to you again for this?

Yes, please do.

thanks,

greg k-h
Paul Schilling | 1 Nov 15:57 2011
Picon

Re: [PATCH 02/14] ARM : SAMSUNG : Add RS485 support.

I am working on resubmitting this stuff right now.  I have 14 patches
that should be
broken into more like 20 patches.  Most of them are ARM S3C and
specifically S3C2416 patches.
I am working on a patch right now to fix a Atomic wait in the DMA
code.  That causes
20 milliseconds of no interrupts whenever a sound is played on the samsung S3C
platform.

The code below wasn't supposed to go out and I have patch that removes
that chunk
of code almost ready that just needs testing before I send it.

On Tue, Nov 1, 2011 at 7:18 AM, Alan Cox <alan <at> linux.intel.com> wrote:
>> +config SAMSUNG_HAS_RS485
>> +     bool "Enable RS485 support for Samsung"
>> +     depends on SERIAL_SAMSUNG && (MACH_CONDOR2440 ||
>> MACH_CONDOR2416 || MACH_MINI2440)
>> +     default y if (MACH_CONDOR2440 || MACH_CONDOR2416)
>> +     default n if (MACH_MINI2440)
>
> There really needs to be more ARM thinking about doing this sort of
> stuff at runtime. If you can detect the board type at runtime then you
> need to be moving towards kicking board specifics out of the depends,
> and treating it as an "include support for this, if the board has it"
> so you can move towards less build time only configuration.
>

The chunk of code that says FIXME is an optimization that could be
implemented to
(Continue reading)


Gmane