linux-kernel - Re: [PATCH v3 1/3] tegra, serial8250: add ->handle_break() uart

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Apr 2012 10:36:19 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	gregkh@...uxfoundation.org,
	Sudhakar Mamillapalli <sudhakar@...com>,
	linux-kernel@...r.kernel.org, ArndBergmannarnd@...db.de,
	Grant Likely <grant.likely@...retlab.ca>,
	linux-serial@...r.kernel.org, Colin Cross <ccross@...roid.com>,
	Olof Johansson <olof@...om.net>,
	Nhan H Mai <nhan.h.mai@...el.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Alan Cox <alan@...ux.intel.com>
Subject: Re: [PATCH v3 1/3] tegra, serial8250: add ->handle_break() uart_port op

On Tue, Apr 10, 2012 at 8:53 AM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 04/09/2012 01:48 PM, Dan Williams wrote:
>> The "KT" serial port has another use case for a "received break" quirk,
>> so before adding another special case to the 8250 core take this
>> opportunity to push such quirks out of the core and into a uart_port op.
>
>> diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
> ...
>> +CONFIG_SERIAL_TEGRA=y
>
> Instead of that,
>
>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> ...
>> +# FIXME remove this option when Tegra completes conversion to open firmware
>> +config SERIAL_TEGRA
>> +     bool "Tegra serial port support"
>> +     depends on SERIAL_OF_PLATFORM=y
>> +     help
>> +       If you have a machine based on NVIDIA Tegra you can enable its
>> +       onboard serial ports by enabling this option.
>> +
>
> Can we just make that default y if ARCH_TEGRA?
>
> defconfig changes are apparently a little touchy.
>
> Actually, why even introduce a new config variable; why not replace the
> ifdefs in of_serial.[ch] with CONFIG_ARCH_TEGRA?

Nice, yes, that makes things a bit cleaner.

>> --- a/arch/arm/mach-tegra/devices.h
>> +++ b/arch/arm/mach-tegra/devices.h
>> @@ -53,5 +53,4 @@ extern struct platform_device tegra_i2s_device1;
>>  extern struct platform_device tegra_i2s_device2;
>>  extern struct platform_device tegra_das_device;
>>  extern struct platform_device tegra_pcm_device;
>> -
>>  #endif
>
> That's left over from a previous patch version.

yep.

>> @@ -84,6 +106,9 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
>>               | UPF_FIXED_PORT | UPF_FIXED_TYPE;
>>       port->dev = &ofdev->dev;
>>
>> +     if (type == PORT_TEGRA)
>> +             port->handle_break = tegra_serial_handle_break;
>
> This is going to mean that everything in 8250.c:uart_config[] will move
> into the exact same data structure in of_serial.c eventually, so I still
> don't see the point of this exercise. But, I guess I won't argue against
> it any more.

To me serial8250_config is about serial port geometries, uart_port ops
are about quirks.  Once open firmware needs to deal with a serial port
with a standard geometry but with a runtime quirk this approach of
just looking at the type will need to be revisited.  The fact that
'PORT_TEGRA' is enough to identify the geometry and the quirk is
serendipitous.

>> diff --git a/include/linux/of_serial.h b/include/linux/of_serial.h
> ...
>> + * FIXME remove this file when tegra finishes conversion to open firmware,
>
> remove this *prototype* not *file*?

The entire file should go away since it is only there to export
tegra_serial_handle_break to the deprecated board files.  Once this is
open firmware only tegra_serial_handle_break can be marked static,
right?

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/