Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
Either everything is dynamic, or everything follows proper minor assignment process. Ultimately everything should probably be dynamic, but trying to get there in one step will simply mean we never get there at all. Alan -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
On Sun, 26 Jan 2014 22:09:07 +0100 Pavel Machek pa...@ucw.cz wrote: On Thu 2014-01-23 19:36:33, Mark Brown wrote: On Thu, Jan 23, 2014 at 07:47:56PM +0100, Tomasz Figa wrote: On 23.01.2014 19:40, Mark Brown wrote: We'd need to leave it user selectable rather than enabling it for ARM, the whole reason this got noticed is that people are trying to build kernels that support a wider range of devices for ARM. What about making it depend on !MULTIPLATFORM and enabled by default? That'd work, but if we're doing that then substituting in the dynamic assignment only when we hit a collision seems smoother and more general. That seems like a mess. I had enough fun debugging WTF is going on with my serials as is... Plus... collision can happen at runtime when you insert BT CF card... at that point it is too late to reassign. Agreed entirely - you want predictability here, plus making it happen by magic is going to do the nut of anyone trying to figure out why kernel A works on their platform and kernel B doesn't. It needs to be something you choose to turn on as compatibility, like old sysfs files and so forth. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
On Fri, 24 Jan 2014 12:03:09 + Mark Brown broo...@kernel.org wrote: On Thu, Jan 23, 2014 at 09:33:21PM +, Alan Cox wrote: Mark Brown broo...@kernel.org wrote: I don't see how we can meaningfully test this on a platform - the kernel would have to be pretty demented to care, it's userspace that cares and that's not really tied to individual serial drivers but is where we mainly need coverage. Which is why I think we want to enable it gradually and platform by platform as that platform or arch maintainer judges it appropriate given their knowledge of their platform(s). I don't see how that follows? For the most part architecture maintainers aren't going to be able to say too much about which userspaces are being run on their platforms if the architecture has any kind of widespread use. For most architectures I suspect that they do have a pretty good idea. ARM is a bit different but I imagine the various platform specific maintainers are the ones who have that knowledge Alan -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
I had earlier submitted a patch [1] to remove the hard coded major/minor number for Samsung UART driver, but that was rejected because of userspace breakage. Without this patch, Samsung UART driver can't bind to the hard-coded device node. Changing the default major/minor will also not help to fix the objections raised in [1]. Would you please suggest a way forward? [1] https://lkml.org/lkml/2013/12/27/2 So to go and try and put this to bed properly I would suggest the following way forward. We add CONFIG_LEGACY_STATIC_TTY Some platforms historically used static device nodes for the console devices. Select this if you are building a kernel for an old system which has a static /dev. Note that because some devices historically used incorrect clashing numbering this may prevent you building a single kernel which can be booted on multiple platforms. And then we do .nr = CONFIG_SERIAL_SAMSUNG_UARTS, .cons = S3C24XX_SERIAL_CONSOLE, .dev_name = S3C24XX_SERIAL_NAME, #ifdef CONFIG_LEGACY_STATIC_TTY .major = S3C24XX_SERIAL_MAJOR, .minor = S3C24XX_SERIAL_MINOR, #endif for the afflicted ports (and anyone else who wants to migrate) We can then enable that config option for ARM (and in time for any other architecture that turns out to need/want it). Eventually it can go away (not that its exactly doing any harm if it doesnt). Does that sound a valid way forward for everyone ? Alan -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
On Thu, 23 Jan 2014 19:36:33 + Mark Brown broo...@kernel.org wrote: On Thu, Jan 23, 2014 at 07:47:56PM +0100, Tomasz Figa wrote: On 23.01.2014 19:40, Mark Brown wrote: We'd need to leave it user selectable rather than enabling it for ARM, the whole reason this got noticed is that people are trying to build kernels that support a wider range of devices for ARM. What about making it depend on !MULTIPLATFORM and enabled by default? That'd work, but if we're doing that then substituting in the dynamic assignment only when we hit a collision seems smoother and more general. Or we could just make the core ignore all hard coded numbers if this is set rather than putting ifdefs in the drivers. That strikes me as rather more risky. We can propogate it through the drivers as we are sure it is safe to do so on that platform and encourage driver authors to migrate. Better than a big bang and the inevitable fallout. We do want it user selectable, because we want people to leave it off unless they have a need for it - that then becomes a path towards eventually getting rid of them static identifiers for good. Alan -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
On Thu, 23 Jan 2014 20:05:09 + Mark Brown broo...@kernel.org wrote: On Thu, Jan 23, 2014 at 07:51:44PM +, Alan Cox wrote: That strikes me as rather more risky. We can propogate it through the drivers as we are sure it is safe to do so on that platform and encourage driver authors to migrate. Better than a big bang and the inevitable fallout. I don't see how we can meaningfully test this on a platform - the kernel would have to be pretty demented to care, it's userspace that cares and that's not really tied to individual serial drivers but is where we mainly need coverage. Which is why I think we want to enable it gradually and platform by platform as that platform or arch maintainer judges it appropriate given their knowledge of their platform(s). Alan -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
On Tue, 21 Jan 2014 00:16:57 + Russell King - ARM Linux li...@arm.linux.org.uk wrote: [I did post a reply to this while on my phone but it got rejected] On Mon, Jan 20, 2014 at 11:47:34PM +, Alan Cox wrote: But yes I agree about the idiom, but a definite NAK to any attempts to plaster over this grand screwup by crapping in the tty core. Your turd, deal with it locally in the ARM code if you can't apply common sense and just go dynamic. I believe at the time there was no one maintaining the device list to _do_ that allocation - AMBA PL011 came along in 2005 after (I believe) hpa stopped looking after that list. git log Documentation/devices.txt So, please tell me how a number could be allocated properly without the device numbers list being maintained? It was being maintained I've no problem with going dynamic, and I suggest that you get a sense of perspective rather than just spouting rubbish from on high. I suggest you take a harder look at the actual history rather than your revisionist one and then apologise. The simple way to sort this out is to go dynamic as first proposed. The more complicated way *IFF* Ben can show an actual systems that break is for the ARM folks to bury a Use ancient static device mapping KConfig entry into the arch Kconfig - which can then go away after a while. Alan -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
I had earlier submitted a patch [1] to remove the hard coded major/minor number for Samsung UART driver, but that was rejected because of userspace breakage. Without this patch, Samsung UART driver can't bind to the hard-coded device node. Changing the default major/minor will also not help to fix the objections raised in [1]. Would you please suggest a way forward? [1] https://lkml.org/lkml/2013/12/27/2 The dynamic major/minor is the right patch. If the userspace breaks then the userspace was broken, but I see no evidence in the discussion that the userspace broke. 204,64 belongs to Altix so neither of the clashing drivers should use it. We had a table to stop messes like this, and we have dynamic numbering to stop the table being needed for the future 50 = /dev/ttyIOC0 Altix serial card ... 81 = /dev/ttyIOC31 Altix serial card Thats what the list says. Samsung should have followed the rules, they didn't so they get to pick up the pieces. The Amba driver wants moving as well. It's easy. If you want something to be ABI then make sure you get it upstream first, if not you get to own all the pain down the line. Hacking up the core code to paper over this crap is not on. We've been insisting firmly and robustly for years that people don't keep borrowing names and numbers they are not allocated, and use dynamic values whenever possible. If the hardware isn't present then the driver shouldn't even register with the tty layer in the first place so it doesn't make any resource differeneces either for properly written code. Alan -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
The first bit is easy... but we need to add locks to every serial driver to prevent two probes operating concurrently... The bus probe should already be serializing surely ? -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
On Mon, 20 Jan 2014 23:14:57 +
Mark Brown broo...@kernel.org wrote:
On Mon, Jan 20, 2014 at 09:43:05PM +, Alan Cox wrote:
The dynamic major/minor is the right patch. If the userspace breaks then
the userspace was broken, but I see no evidence in the discussion that
the userspace broke.
The userspace breakage is that if someone has a static /dev that doesn't
handle any dynamic devices then renumbering the device will cause that
static /dev to stop matching the kernel.
Diddums and you've only provided theoretical cases not real world ones.
They should have followed proper practice and reserved their minors. The
device number belongs to the Altix. The driver should just move.
Thats what the list says. Samsung should have followed the rules, they
didn't so they get to pick up the pieces. The Amba driver wants moving as
well. It's easy. If you want something to be ABI then make sure you get
it upstream first, if not you get to own all the pain down the line.
This stuff is all upstream already, a quick check suggests both drivers
predate git - it's been noticed because the ARM multiplatform work has
caused people to try booting kernels with both built in.
So ARM people didn't follow the policy on allocating device minors even
within their own community and got burned by it. That's despite having
previously been burned by abusing the ttyS0 8250 major/minor in the same
way, for the same purposes, and creating the same mess.
{facepalm...}
If the hardware isn't present then the driver shouldn't even register
with the tty layer in the first place so it doesn't make any resource
differeneces either for properly written code.
Right, that's not the idiom that has been followed by any of serial
drivers though so needs fixing too.
Actally some drivers do get this right but not many. ehv-bc for example
does.
But yes I agree about the idiom, but a definite NAK to any attempts to
plaster over this grand screwup by crapping in the tty core. Your turd,
deal with it locally in the ARM code if you can't apply common sense and
just go dynamic.
And please, after screwing this up twice - *learn* from the mess.
Alan
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: exynos4: fix incorrect pad configuration for keypad row lines
SMDKV310 board does not have pull-up resistors populated for the keypad row lines (unlike the smdk boards for the previous Samsung SoC's). So the pad pull-up for all keypad row lines should be enabled for smdkv310 board. So does this change the behaviour of existing boards, and if so isn't it the SMDKV310 that hould be providing the alternate gpio configuration function ? -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Add unified interrupt handler for s3c64xx and later SoC's
On Wed, 10 Aug 2011 15:51:19 +0530 Thomas Abraham thomas.abra...@linaro.org wrote: s3c64xx and later SoC's include the interrupt mask and pending registers in the uart controller, unlike the s3c24xx SoC's which have these registers in the interrupt controller. When the mask and pending registers are part of the uart controller, a unified interrupt handler can handle the tx/rx interrupt. With this, the static reservation of interrupt numbers for the uart tx/rx/err interrupts in the linux irq space is not required and simplifies adding device tree support. Really only hardware changes so for the tty touching aspect of it Acked-by: Alan Cox a...@linux.intel.com -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
