On 28 December 2013 00:14, Greg KH <gregkh(a)linuxfoundation.org> wrote:
> On Fri, Dec 27, 2013 at 03:47:31PM +0530, Tushar Behera wrote:
>> On 27 December 2013 12:08, Greg KH <gregkh(a)linuxfoundation.org> wrote:
>> > On Fri, Dec 27, 2013 at 12:00:20PM +0530, Tushar Behera wrote:
>> >> On 27 December 2013 10:48, Greg KH <gregkh(a)linuxfoundation.org> wrote:
>> >> > On Fri, Dec 27, 2013 at 10:37:28AM +0530, Tushar Behera wrote:
>>
>> [ ... ]
>>
>> >> >> @@ -951,8 +949,6 @@ static struct uart_driver s3c24xx_uart_drv = {
>> >> >> .nr = CONFIG_SERIAL_SAMSUNG_UARTS,
>> >> >> .cons = S3C24XX_SERIAL_CONSOLE,
>> >> >> .dev_name = S3C24XX_SERIAL_NAME,
>> >> >> - .major = S3C24XX_SERIAL_MAJOR,
>> >> >> - .minor = S3C24XX_SERIAL_MINOR,
>> >> >
>> >> > Doesn't this break existing systems and configurations that are
>> >> > expecting 204:64 as the location of this serial port?
>> >> >
>> >>
>> >> I tested this on Exynos4210-Origen, Exynos5250-Arndale board, it works
>> >> fine there. I haven't tested on any older boards.
>> >
>> > How did it work? You are relying on some userspace tools to do this
>> > properly, right? What about systems without those specific tools?
>> >
>>
>> Enabling CONFIG_DEVTMPFS, all the /dev/ttySAC<n> nodes are generated
>> and the appropriate console is specified through command line
>> argument.
>
> But what about systems that rely on a hard-coded /dev?
>
> Look, I'm all for making everyone use devtmpfs, but just changing
> major:minor numbers for drivers isn't ok, as you are changing the
> userspace ABI for the device.
>
> Please realize what you are asking for here, I really don't think you
> grasp it given that you didn't ask any of the maintainers of this driver
> about the change in the first place.
>
> Please get approval for this patch from others within Linaro before
> sending it out again. Linaro has a process in place for this type of
> thing, please use it, otherwise it makes people like me really grumpy
> and upset and causes me to yell at people at their conferences.
>
> greg k-h
Asking for opinion about this ... Without this patch, I can't get
serial console to come up on Exynos platforms when amba-pl011 driver
enabled. But Greg is particularly not at all happy with this patch.
Any comments with respect to fixing this issue would be highly
appreciated.
Attaching the complete patch for reference.
--
Tushar Behera
Reworked initial Ben's series for big endian support [1].
Dropped patches that are not directly related to kprobes.
Current set of patches is enough to have functional BE kprobes.
One ARM kprobe test fails on Cortex-A15 boards (TC2 and Keystone2 EVM),
while it passes on Pandaboard. The issue is not related to this series
and already present in v3.13-rc7. I'll try to look into it later.
v1..v2: Fixed coprocessor instruction building for ARM tests in the patch
"ARM: kprobes-test: use <asm/opcodes.h> for ARM instruction building"
Based on v3.13-rc7.
[1] http://www.spinics.net/lists/arm-kernel/msg285210.html
Ben Dooks (4):
ARM: kprobes: fix instruction fetch order with <asm/opcodes.h>
ARM: kprobes-test: use <asm/opcodes.h> for instruction accesses
ARM: kprobes-test: use <asm/opcodes.h> for ARM instruction building
ARM: kprobes-test: use <asm/opcodes.h> for Thumb instruction building
Taras Kondratiuk (1):
ARM: kprobes-test: Workaround GAS .align bug
arch/arm/kernel/kprobes-common.c | 19 +-
arch/arm/kernel/kprobes-test-arm.c | 603 +++++++++++++++++-----------------
arch/arm/kernel/kprobes-test-thumb.c | 447 ++++++++++++-------------
arch/arm/kernel/kprobes-test.c | 13 +-
arch/arm/kernel/kprobes-test.h | 2 +-
arch/arm/kernel/kprobes-thumb.c | 20 +-
arch/arm/kernel/kprobes.c | 9 +-
7 files changed, 562 insertions(+), 551 deletions(-)
--
1.7.9.5