On Mon, 27 Jan 2014, Russell King - ARM Linux wrote:
> On Sun, Jan 26, 2014 at 11:30:00PM -0500, Nicolas Pitre wrote:
> > On Sun, 26 Jan 2014, Russell King - ARM Linux wrote:
> >
> > > On Tue, Jan 21, 2014 at 12:45:05AM +, Alan Cox wrote:
> > > > Peter handed it on. Try using git log on
On Sun, Jan 26, 2014 at 11:30:00PM -0500, Nicolas Pitre wrote:
> On Sun, 26 Jan 2014, Russell King - ARM Linux wrote:
>
> > On Tue, Jan 21, 2014 at 12:45:05AM +, Alan Cox wrote:
> > > Peter handed it on. Try using git log on Documentation/devices.txt. It
> > > still gets updates.
> > >
> > >
> 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
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-kernel
On Sun, Jan 26, 2014 at 11:30:00PM -0500, Nicolas Pitre wrote:
On Sun, 26 Jan 2014, Russell King - ARM Linux wrote:
On Tue, Jan 21, 2014 at 12:45:05AM +, Alan Cox wrote:
Peter handed it on. Try using git log on Documentation/devices.txt. It
still gets updates.
Perhaps you'd
On Mon, 27 Jan 2014, Russell King - ARM Linux wrote:
On Sun, Jan 26, 2014 at 11:30:00PM -0500, Nicolas Pitre wrote:
On Sun, 26 Jan 2014, Russell King - ARM Linux wrote:
On Tue, Jan 21, 2014 at 12:45:05AM +, Alan Cox wrote:
Peter handed it on. Try using git log on
On Sun, 26 Jan 2014, Russell King - ARM Linux wrote:
> On Tue, Jan 21, 2014 at 12:45:05AM +, Alan Cox wrote:
> > Peter handed it on. Try using git log on Documentation/devices.txt. It
> > still gets updates.
> >
> > Perhaps you'd care to stick to reality and fix the tree instead of trying
>
On Fri, Jan 24, 2014 at 02:38:59PM +, Alan Cox wrote:
> Mark Brown wrote:
> > 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
On Sun, 26 Jan 2014 22:09:07 +0100
Pavel Machek 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,
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
On Tue, Jan 21, 2014 at 12:45:05AM +, Alan Cox wrote:
> Peter handed it on. Try using git log on Documentation/devices.txt. It
> still gets updates.
>
> Perhaps you'd care to stick to reality and fix the tree instead of trying
> to excuse the mess ?
Perhaps returning to reality might be
On Tue, Jan 21, 2014 at 12:45:05AM +, Alan Cox wrote:
Peter handed it on. Try using git log on Documentation/devices.txt. It
still gets updates.
Perhaps you'd care to stick to reality and fix the tree instead of trying
to excuse the mess ?
Perhaps returning to reality might be
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
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,
On Fri, Jan 24, 2014 at 02:38:59PM +, Alan Cox wrote:
Mark Brown broo...@kernel.org wrote:
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
On Sun, 26 Jan 2014, Russell King - ARM Linux wrote:
On Tue, Jan 21, 2014 at 12:45:05AM +, Alan Cox wrote:
Peter handed it on. Try using git log on Documentation/devices.txt. It
still gets updates.
Perhaps you'd care to stick to reality and fix the tree instead of trying
to excuse
On Fri, 24 Jan 2014 12:03:09 +
Mark Brown wrote:
> On Thu, Jan 23, 2014 at 09:33:21PM +, Alan Cox wrote:
> > Mark Brown 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
On Thu, Jan 23, 2014 at 09:33:21PM +, Alan Cox wrote:
> Mark Brown 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
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
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
On Thu, 23 Jan 2014 20:05:09 +
Mark Brown 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
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
On Thu, 23 Jan 2014 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
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
On 23.01.2014 19:40, Mark Brown wrote:
On Thu, Jan 23, 2014 at 06:04:23PM +, Alan Cox wrote:
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).
On Thu, Jan 23, 2014 at 06:04:23PM +, Alan Cox wrote:
> 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).
We'd need to leave it user
> 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
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
On Thu, Jan 23, 2014 at 06:04:23PM +, Alan Cox wrote:
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).
We'd need to leave it user selectable
On 23.01.2014 19:40, Mark Brown wrote:
On Thu, Jan 23, 2014 at 06:04:23PM +, Alan Cox wrote:
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).
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
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
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
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
On Tue, Jan 21, 2014 at 04:59:35PM +, Mark Brown wrote:
> On Mon, Jan 20, 2014 at 11:47:34PM +, Alan Cox wrote:
> > They should have followed proper practice and reserved their minors. The
> > device number belongs to the Altix. The driver should just move.
>
> They should have done that
On Mon, Jan 20, 2014 at 11:47:34PM +, Alan Cox wrote:
> Mark Brown wrote:
> > On Mon, Jan 20, 2014 at 09:43:05PM +, Alan Cox wrote:
> > 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
> >
On Tue, Jan 21, 2014 at 09:03:40AM +, Alan Cox wrote:
> On Tue, 21 Jan 2014 00:16:57 +
> Russell King - ARM Linux 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
On Tue, Jan 21, 2014 at 09:25:31AM +, One Thousand Gnomes wrote:
> > static DEFINE_MUTEX(foo_mutex);
> > static unsigned foo_devices;
> >
> > static int foo_probe(struct platform_device *pdev)
> > {
> > int ret;
> >
> > mutex_lock(_mutex);
> > if (foo_devices++ == 0)
> >
> > So, let's go back to your original worry, what are you concerned about?
> > A device being removed while probe() is called?
>
> My concern is that we're turning something which should be simple into
> something unnecessarily complex. By that, I mean something along the
> lines of:
Or in
On Tue, 21 Jan 2014 00:16:57 +
Russell King - ARM Linux 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
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
So, let's go back to your original worry, what are you concerned about?
A device being removed while probe() is called?
My concern is that we're turning something which should be simple into
something unnecessarily complex. By that, I mean something along the
lines of:
Or in fact more
On Tue, Jan 21, 2014 at 09:25:31AM +, One Thousand Gnomes wrote:
static DEFINE_MUTEX(foo_mutex);
static unsigned foo_devices;
static int foo_probe(struct platform_device *pdev)
{
int ret;
mutex_lock(foo_mutex);
if (foo_devices++ == 0)
On Tue, Jan 21, 2014 at 09:03:40AM +, Alan Cox wrote:
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
On Mon, Jan 20, 2014 at 11:47:34PM +, Alan Cox wrote:
Mark Brown broo...@kernel.org wrote:
On Mon, Jan 20, 2014 at 09:43:05PM +, Alan Cox wrote:
The userspace breakage is that if someone has a static /dev that doesn't
handle any dynamic devices then renumbering the device will
On Tue, Jan 21, 2014 at 04:59:35PM +, Mark Brown wrote:
On Mon, Jan 20, 2014 at 11:47:34PM +, Alan Cox wrote:
They should have followed proper practice and reserved their minors. The
device number belongs to the Altix. The driver should just move.
They should have done that about a
On Mon, Jan 20, 2014 at 04:26:23PM -0800, Greg KH wrote:
> On Tue, Jan 21, 2014 at 12:07:06AM +, Russell King - ARM Linux wrote:
> > On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
> > > On Mon, Jan 20, 2014 at 11:16:03PM +, Russell King - ARM Linux wrote:
> > > > I don't believe
On Tue, Jan 21, 2014 at 12:07:06AM +, Russell King - ARM Linux wrote:
> On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
> > On Mon, Jan 20, 2014 at 11:16:03PM +, Russell King - ARM Linux wrote:
> > > I don't believe the driver model has any locking to prevent a drivers
> > >
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.
On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
> On Mon, Jan 20, 2014 at 11:16:03PM +, Russell King - ARM Linux wrote:
> > I don't believe the driver model has any locking to prevent a drivers
> > ->probe function running concurrently with it's ->remove function for
> > two (or more)
On Mon, Jan 20, 2014 at 11:35:41PM +, Alan Cox wrote:
> > 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 ?
Yes, it better be, otherwise that bus is badly
On Mon, Jan 20, 2014 at 11:16:03PM +, Russell King - ARM Linux wrote:
> On Mon, Jan 20, 2014 at 03:11:41PM -0800, Greg KH wrote:
> > On Mon, Jan 20, 2014 at 09:32:06PM +, Russell King - ARM Linux wrote:
> > > On Mon, Jan 20, 2014 at 01:16:01PM -0800, Greg KH wrote:
> > > > On Mon, Jan 20,
On Mon, 20 Jan 2014 23:14:57 +
Mark Brown 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 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-kernel" in
the body of a message to
On Mon, Jan 20, 2014 at 11:14:57PM +, Mark Brown wrote:
> On Mon, Jan 20, 2014 at 09:43:05PM +, Alan Cox wrote:
> > 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
On Mon, Jan 20, 2014 at 03:11:41PM -0800, Greg KH wrote:
> On Mon, Jan 20, 2014 at 09:32:06PM +, Russell King - ARM Linux wrote:
> > On Mon, Jan 20, 2014 at 01:16:01PM -0800, Greg KH wrote:
> > > On Mon, Jan 20, 2014 at 10:05:30AM +, Russell King - ARM Linux wrote:
> > > > On Mon, Jan 20,
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
On Mon, Jan 20, 2014 at 09:32:06PM +, Russell King - ARM Linux wrote:
> On Mon, Jan 20, 2014 at 01:16:01PM -0800, Greg KH wrote:
> > On Mon, Jan 20, 2014 at 10:05:30AM +, Russell King - ARM Linux wrote:
> > > On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
> > > >
> 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
On Mon, Jan 20, 2014 at 01:16:01PM -0800, Greg KH wrote:
> On Mon, Jan 20, 2014 at 10:05:30AM +, Russell King - ARM Linux wrote:
> > On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
> > > uart_register_driver call binds the driver to a specific device
> > > node through
On Mon, Jan 20, 2014 at 10:05:30AM +, Russell King - ARM Linux wrote:
> On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
> > uart_register_driver call binds the driver to a specific device
> > node through tty_register_driver call. This should typically happen
> > during device
On Mon, Jan 20, 2014 at 05:23:21PM +0530, Tushar Behera wrote:
> On 20 January 2014 15:35, Russell King - ARM Linux
> wrote:
> > On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
> >> uart_register_driver call binds the driver to a specific device
> >> node through
On 20 January 2014 15:35, Russell King - ARM Linux
wrote:
> On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
>> uart_register_driver call binds the driver to a specific device
>> node through tty_register_driver call. This should typically happen
>> during device probe call.
>>
>>
On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
> uart_register_driver call binds the driver to a specific device
> node through tty_register_driver call. This should typically happen
> during device probe call.
>
> In a multiplatform scenario, it is possible that multiple serial
>
On 20 January 2014 15:35, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
uart_register_driver call binds the driver to a specific device
node through tty_register_driver call. This should typically happen
during device
On Mon, Jan 20, 2014 at 05:23:21PM +0530, Tushar Behera wrote:
On 20 January 2014 15:35, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
uart_register_driver call binds the driver to a specific device
node through
On Mon, Jan 20, 2014 at 10:05:30AM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
uart_register_driver call binds the driver to a specific device
node through tty_register_driver call. This should typically happen
during device probe
On Mon, Jan 20, 2014 at 01:16:01PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 10:05:30AM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
uart_register_driver call binds the driver to a specific device
node through
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
On Mon, Jan 20, 2014 at 09:32:06PM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 01:16:01PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 10:05:30AM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
uart_register_driver
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
On Mon, Jan 20, 2014 at 03:11:41PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 09:32:06PM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 01:16:01PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 10:05:30AM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at
On Mon, Jan 20, 2014 at 11:14:57PM +, Mark Brown wrote:
On Mon, Jan 20, 2014 at 09:43:05PM +, Alan Cox wrote:
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
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-kernel in
the body of a message to
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
On Mon, Jan 20, 2014 at 11:16:03PM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 03:11:41PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 09:32:06PM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 01:16:01PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at
On Mon, Jan 20, 2014 at 11:35:41PM +, Alan Cox wrote:
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 ?
Yes, it better be, otherwise that bus is badly broken.
On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 11:16:03PM +, Russell King - ARM Linux wrote:
I don't believe the driver model has any locking to prevent a drivers
-probe function running concurrently with it's -remove function for
two (or more) devices.
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
On Tue, Jan 21, 2014 at 12:07:06AM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 11:16:03PM +, Russell King - ARM Linux wrote:
I don't believe the driver model has any locking to prevent a drivers
-probe
On Mon, Jan 20, 2014 at 04:26:23PM -0800, Greg KH wrote:
On Tue, Jan 21, 2014 at 12:07:06AM +, Russell King - ARM Linux wrote:
On Mon, Jan 20, 2014 at 03:51:28PM -0800, Greg KH wrote:
On Mon, Jan 20, 2014 at 11:16:03PM +, Russell King - ARM Linux wrote:
I don't believe the driver
On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
uart_register_driver call binds the driver to a specific device
node through tty_register_driver call. This should typically happen
during device probe call.
In a multiplatform scenario, it is possible that multiple serial
82 matches
Mail list logo
