arch/mips/loongson2ef/common/serial.c: In function 'serial_init':
>> arch/mips/loongson2ef/common/serial.c:66:4: error: 'loongson_uart_base'
>> undeclared (first use in this function); did you mean
>> 'loongson
arch/mips/loongson2ef/common/serial.c: In function 'serial_init':
>> arch/mips/loongson2ef/common/serial.c:66:4: error: 'loongson_uart_base'
>> undeclared (first use in this function); did you mean
>> 'loongson
arch/mips/loongson2ef/common/serial.c: In function 'serial_init':
>> arch/mips/loongson2ef/common/serial.c:66:4: error: 'loongson_uart_base'
>> undeclared (first use in this function)
66 |loongson_uart_base;
|^~
arch/mips/
to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
arch/mips/loongson2ef/common/serial.c: In fu
v3.20 with subject updated to:
"ARM: davinci: serial.c: remove unused serial_read_reg()"
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
Remove function serial_read_reg() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
arch/arm/mach-davinci/serial.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach
It's a duplicate of sead3-platform.c and is not even compiled.
Remove it before we start fixing up IRQ assignments.
Signed-off-by: Andrew Bresticker
Reviewed-by: Qais Yousef
Tested-by: Qais Yousef
---
No changes from v1.
---
arch/mips/mti-sead3/sead3-serial.c
It's a duplicate of sead3-platform.c and is not even compiled.
Remove it before we start fixing up IRQ assignments.
Signed-off-by: Andrew Bresticker
---
arch/mips/mti-sead3/sead3-serial.c | 45 --
1 file changed, 45 deletions(-)
delete mode 100644 arch
> No, this is a fundamental problem. You don't
> refcount
> a pointer, you refcount a data structure.
> But this is insufficient. We need to make
> sure the pointer points to valid memory.
I understand. But a typical definition of ref-count
requires the count in the data structure to be
equal to
Am Freitag, 22. Dezember 2006 20:08 schrieb J:
> > This problem will need some deeper surgery probably
> > involving
> > removal of the refcounting.
>
> Refcounting may be OK if used consistently.
> It is not OK when some pointers are ref-counted,
> but other (in serial_table) are not (like it i
> This problem will need some deeper surgery probably
> involving
> removal of the refcounting.
Refcounting may be OK if used consistently.
It is not OK when some pointers are ref-counted,
but other (in serial_table) are not (like it is
in the current version).
As for the deeper surgery, what d
Am Mittwoch, 20. Dezember 2006 23:24 schrieb J:
> > Could you test the attached patch against 2.6?
>
> Alas, I only have an old 2.4 right now.
> May be I will install 2.6 later (in few weeks).
> Currently I am just trying to read 2.6 code with my
> eyes.
>
> I studied the patch, which you sent.
>
On Wed, Dec 20, 2006 at 02:39:39PM -0800, J wrote:
> Thank you for your reply.
>
> > Which usb-serial driver are you having problems
> > with? What is the oops trace?
> > What version of the 2.4 kernel are you using?
>
> I was told to fix an old embedded device, which my
> company bought from
Thank you for your reply.
> Which usb-serial driver are you having problems
> with? What is the oops trace?
> What version of the 2.4 kernel are you using?
I was told to fix an old embedded device, which my
company bought from somebody many years ago.
It appears to have kernel 2.4.9 and a pat
lve this issue. I will have to study more.
> I suppose the last time I looked at that code, khubd
> still took BKL. Or I overlooked the race.
Well, as I already mentioned, BKL/lock_kernel appears
to be completely compiled out of my build, so it is
no help for me.
Also, in my opinion, if usb-se
Am Mittwoch, 20. Dezember 2006 16:10 schrieb Alan Stern:
> On Wed, 20 Dec 2006, Oliver Neukum wrote:
> > People, do we take BKL in khubd?
>
> Nope.
OK. I've taken measures to correct the problem.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe
On Wed, Dec 20, 2006 at 11:32:31AM -0800, J wrote:
> Thank you for the explanation.
>
> > serial_close is safe because serial_disconnect
> > lowers the refcount
>
> Sorry, I meant serial_open, as in my original example.
>
> I am currently trying to fix a legacy 2.4 based USB
> driver and I am ha
s.
Could you test the attached patch against 2.6?
Regards
Oliver
--- drivers/usb/serial/usb-serial.c.alt 2006-12-17 14:57:40.0 +0100
+++ drivers/usb/serial/usb-serial.c 2006-12-20 18:22:41.0 +0100
@@ -59,6 +59,7 @@
static int debug;
static struct usb_serial
Thank you for the explanation.
> serial_close is safe because serial_disconnect
> lowers the refcount
Sorry, I meant serial_open, as in my original example.
I am currently trying to fix a legacy 2.4 based USB
driver and I am having various races,
serial_open/usb_serial_disconnect is the most li
On Wed, 20 Dec 2006, Oliver Neukum wrote:
> The data structure to protect is serial_table. Everything else is
> protected by refcounts. Therefore the interesting race is between
> open and disconnect. Open is called with BKL (fs/char_dev.c::chrdev_open)
>
> Now, regarding disconnect. It used to b
Am Dienstag, 19. Dezember 2006 23:33 schrieb J:
> Thank you for the response.
>
> > This code depends on protection from BKL.
>
> Really? I cannot find many lock_kernel calls in
> USB directory and those, which I can find,
> don't appear to protect usb_serial_disconnect
> and serial_close from
Thank you for the response.
> This code depends on protection from BKL.
Really? I cannot find many lock_kernel calls in
USB directory and those, which I can find,
don't appear to protect usb_serial_disconnect
and serial_close from being called at the same time.
May be the protection is at a hi
Am Dienstag, 19. Dezember 2006 20:21 schrieb J:
> Hi,
> I read usb-serial.c code (in 2.6.19) and I cannot
> figure out how it is
> supposed to prevent race condition and premature
> deletion of usb_serial
> structure. I see that the code attempts to protect
> usb_serial by r
Hi,
I read usb-serial.c code (in 2.6.19) and I cannot
figure out how it is
supposed to prevent race condition and premature
deletion of usb_serial
structure. I see that the code attempts to protect
usb_serial by ref
counting, but it does not appear to be correct. I am
not 100% sure in my
findings
From: "Jonathan Lundell" <[EMAIL PROTECTED]>
> The other CPU servicing the interrupt, was the question. cli()
> doesn't affect that. This could presumably happen if shutdown() gets
> run on a non-interrupt-servicing CPU, or if interrupts are
> dynamically routed (eg round-robin).
Ah. Missed that.
At 9:51 AM -0400 2001-06-22, Stuart MacDonald wrote:
>From: "kees" <[EMAIL PROTECTED]>
>> What may happen on a SMP machine if a serial port has been closed and the
>> closing stage is at shutdown() in serial.c in the call to free_IRQ and
>> BEFORE the IR
From: "kees" <[EMAIL PROTECTED]>
> What may happen on a SMP machine if a serial port has been closed and the
> closing stage is at shutdown() in serial.c in the call to free_IRQ and
> BEFORE the IRQ is really shutdown, a new character arrives which causes an
> IRQ? I
Hi
What may happen on a SMP machine if a serial port has been closed and the
closing stage is at shutdown() in serial.c in the call to free_IRQ and
BEFORE the IRQ is really shutdown, a new character arrives which causes an
IRQ? Is it possible that the OTHER cpu takes this interrupt and causes a
On Wed, May 16, 2001 at 04:12:45PM -0600, Val Henson wrote:
> Anyone know where Ted Tso is? He hasn't posted in several weeks.
> Alan, will you put this in -ac? This patch fixes a bug in serial.c
> that causes a crash on machines with a ST16C654.
I'm around, just swamp
On Thu, May 17, 2001 at 09:49:11AM -0400, Stuart MacDonald wrote:
> Are you using the serial console though? That seems to be
> implied by your problem, but I just want to check.
Yes, I have serial console only on this board.
-VAL
-
To unsubscribe from this list: send the line "unsubscribe linu
From: "Val Henson" <[EMAIL PROTECTED]>
> Anyone know where Ted Tso is? He hasn't posted in several weeks.
Haven't heard from him in a while. I've got a patch or two pending
as well, one of which modifies this code to check for 16c2850s.
Usually he just says he's really busy.
> > Kernel version?
Anyone know where Ted Tso is? He hasn't posted in several weeks.
Alan, will you put this in -ac? This patch fixes a bug in serial.c
that causes a crash on machines with a ST16C654.
On Tue, May 15, 2001 at 09:52:01AM -0400, Stuart MacDonald wrote:
> Kernel version? Distribution? Are y
for the XR16C854 then
> the comment can be made clearer. See patch below.
The revision should always be saved if it's available. Hmm.
I didn't look carefully yesterday. The DLL always contains the
revision for the 85x family. Why do you think it doesn't?
I think your patch below i
On Mon, May 14, 2001 at 03:50:01PM -0400, Stuart MacDonald wrote:
> What version of serial.c? I'm assuming 5.05.
Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
> Define "go kablooey". We haven't noticed any problems, and we s
Jesper Juhl ([EMAIL PROTECTED]) said:
> I have made a patch against 2.4.4-ac8 that makes the change, it is
> below. I guess someone more knowledgeable than me can probably see if
> this is correct. If this is completely bogus, then please just disregard
> this email.
Yup, it's right. My bad.
From: "Val Henson" <[EMAIL PROTECTED]>
> This fixes a bug in the autoconfig_startech_uarts function in
> serial.c. The problem is that 0's are written to the baud rate
> registers in order to detect an XR16C850 or XR16C854. This makes the
> Exar ST16C654 go ka
Hi,
I'm using the 2.4.4-ac8 kernel and found that the pci_xircom_fn()
function in drivers/char/serial.c does not return a value even though it
is defined as returning int. I took a look at the other initializer
functions and they all return 0 (zero) on success, so I assumed that the
co
This fixes a bug in the autoconfig_startech_uarts function in
serial.c. The problem is that 0's are written to the baud rate
registers in order to detect an XR16C850 or XR16C854. This makes the
Exar ST16C654 go kablooey. Saving and restoring the baud rate
registers after the test fix
Same thing for me.
I'm using busybox as init/getty/shell.
Everything works fine with 2.4.2.
With 2.4.3 console output is fine but not input.
Thanks
--
Fabrice Gautier <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
-Original Message-
From: Marc Karasek
To: 'Disconnect '
Sent: 4/19/01 11:49 AM
Subject: RE: Bug in serial.c
I have changed everything to point to /dev/ttyS0. The settings in
lilo.conf (I am booting from a floppy to emulate the embedded space) are
all for ttyS0. Lilo pri
-Original Message-
From: Marc Karasek
To: 'Richard B. Johnson '
Sent: 4/19/01 11:53 AM
Subject: RE: Bug in serial.c
Did something change between 2.4.2 & 2.4.3? Under 2.4.2 I did not have
to init the terminal (are you refering to the host or client side?) and
jus
tering data (login, configuration
> scripts, etc) the terminal does not accept any input.
>
It is not broken. It is used all the while in our embeded systems.
> So far I have been able to debug to the point where I see that the kernel is
> receiving the characters from the serial.c dr
eadless server trying that. Easiest to point it at
/dev/ttyS0 or whatnot.)
>
> So far I have been able to debug to the point where I see that the kernel is
> receiving the characters from the serial.c driver. But it never echos them
> or does anything else with them. I will continue
is
receiving the characters from the serial.c driver. But it never echos them
or does anything else with them. I will continue to look into this at this
end.
I was also wondering if anyone else has seen this or if a patch is avail for
this bug??
Marc Karasek
Sr. Firmware Engineer
iVivity Inc
2-ac21 sets the device to /dev/ttyS1). However it only works
> if I load serial.c as a module AFTER the card is inserted, if serial.c is
> already loaded it doesn't register correctly with a messages similar to
> above. Perhaps I need to check my hotplug setup.
>
> Could your
rom pcmcia_cs-3.1.25).
> OK, I'll take a look at it. I made the patch against -ac21 which I think
> was only synced up to 2.4.3-pre6, I should have mentioned that. Perhaps
> someone added the proper Xircom stuff already or some other change made my
> patch irrelavent. BTW, are you
Tom Sightler wrote:
>
[snip]
> OK, can you try this patch? It's very simple, and is probably not the
> correct fix (the correct fix is probably to add the Xircom card to the
> supported PCI table), but it works for me. I'm not sure why the generic pci
> serial code counts the number of iomem re
> Tom Sightler wrote:
> >
> > Hi all,
> >
> > I saw a discussion on this list about this problem earlier, but could
not
> > find that it had actually been resolved.
>
> That was me :) and no, it doesn't work. Jeff Garzik asked me to enable
> a coup
Tom Sightler wrote:
>
> Hi all,
>
> I saw a discussion on this list about this problem earlier, but could not
> find that it had actually been resolved.
That was me :) and no, it doesn't work. Jeff Garzik asked me to enable
a couple debug #defines in serial.c, apply pat
Hi all,
I saw a discussion on this list about this problem earlier, but could not
find that it had actually been resolved.
With the removal of serial_cb from the 2.4.3pre kernels I can no longer use
the modem of my Xircom adapter. According to the posts in the other thread
serial.c should now
On Fri, Mar 16, 2001 at 09:47:14AM +0100, Gunther Mayer wrote:
> I'm sending this since 3 months to the maintainer ([EMAIL PROTECTED])
> and even submitted to serial.sourceforge.net but never got a reaction.
> Anybody knows if Ted is still active?
Sorry, life's been a bit busy lately, what with t
ivers/char/serial.c-242-origFri Mar 16 09:32:22 2001
+++ linux/drivers/char/serial.c Fri Mar 16 09:34:32 2001
@@ -4175,7 +4175,7 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
-
On Fri, 9 Mar 2001, Alan Cox wrote:
> Date: Fri, 9 Mar 2001 01:14:04 + (GMT)
> From: Alan Cox <[EMAIL PROTECTED]>
> To: Miles Lane <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: 2.4.2-ac15 -- Build fails in serial.c if CONFIG_SERIAL_CONSOLE is
>e
> In serial.c, in function `wait_for_xmitr' at lines 5497 and 5666,
> `ASYNC_NO_FLOW' is undeclared.
Yep. Disable serial console for now. Jeff's serial merge broke serial console
support
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
In serial.c, in function `wait_for_xmitr' at lines 5497 and 5666,
`ASYNC_NO_FLOW' is undeclared.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-i
Date: Mon, 5 Mar 2001 15:37:04 +0300
From: Andrey Panin <[EMAIL PROTECTED]>
I already sent this patch some days ago, but didn't get an answer :(
So, i'm trying to resubmit it.
Thanks for submitting it; the general idea of the patch looks good, but
as prumpf pointed out, the test for
ter error handling in start_pci_pnp_board() function.
>
> Did you test it ?
Partially (without my ISAPNP modem, lack of ISA slots)
>
> > diff -u /linux.vanilla/drivers/char/serial.c /linux/drivers/char/serial.c
> > --- /linux.vanilla/drivers/char/serial.cThu Mar 1 20:15:43
> diff -u /linux.vanilla/drivers/char/serial.c /linux/drivers/char/serial.c
> --- /linux.vanilla/drivers/char/serial.c Thu Mar 1 20:15:43 2001
> +++ /linux/drivers/char/serial.c Fri Mar 2 00:10:29 2001
> @@ -3876,7 +3876,10 @@
> return 0;
> }
>
) function.
Best regards.
--
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc
diff -u /linux.vanilla/drivers/char/serial.c /linux/drivers/char/serial.c
--- /linux.vanilla/drivers/char/serial.cThu
p() return value.
> > > Atached patch should fix this it.
> >
> > humm, have not checked, but it seems as if you don't release the previous
> > successful mappings on failure. Wipe out this message if I was too quick to
> > answer and this is not true. 8)
>
ecked, but it seems as if you don't release the previous
> successful mappings on failure. Wipe out this message if I was too quick to
> answer and this is not true. 8)
Also, the proper return from a failed ioremap is -ENOMEM, so I think
Andrey's serial.c patch should modify some functio
Em Fri, Feb 23, 2001 at 10:53:59AM +0300, Andrey Panin escreveu:
>
> Hi all,
>
> 16x50 serial driver doesn't check ioremap() return value.
> Atached patch should fix this it.
humm, have not checked, but it seems as if you don't release the previous
successful mappings on failure. Wipe out this
ivers/char/serial.c linux/drivers/char/serial.c
--- linux.vanilla/drivers/char/serial.c Thu Feb 22 20:50:18 2001
+++ linux/drivers/char/serial.c Thu Feb 22 23:01:48 2001
@@ -3876,7 +3876,8 @@
return 0;
}
req->io_type = SERIAL_IO_MEM;
- req->iomem_base = i
Just noticed something weird when I tried to minicom into the office to run
a job yesterday morning.
It seems that 2.2.18 (without the PCI_CONFIG in serial.c) works fine, with
respect to flow control in minicom, everything looks great. (and the dmesg
shows the serial ports without any extra
Meelis Roos ([EMAIL PROTECTED]) said:
> 2.4.0-prerelease-ac6 doesn't compile serial on x86 with pnp enabled:
>
> serial.c: In function `probe_serial_pnp':
> serial.c:5187: structure has no member named `device'
> serial.c:5192: structure has no member named `device
2.4.0-prerelease-ac6 doesn't compile serial on x86 with pnp enabled:
serial.c: In function `probe_serial_pnp':
serial.c:5187: structure has no member named `device'
serial.c:5192: structure has no member named `device'
---
Meelis Roos <[EMAIL PROTECTED]>
-
To unsubs
;t it ?
--
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc
diff -u /linux/drivers/char/serial.c.orig /linux/drivers/char/serial.c
--- /linux/drivers/char/serial.c.orig Sun Dec 31 22:49:36 2000
+++ /linux/drivers
Hi Alan,
can you may include the attached patch in one of the next pre19 patches?
It adds the possibility to work with pcmcia modem cards on PowerBooks,
this patch was in for a longer time in the ppc tree of Paul M. and Ben
Herrenschmidt.
Ben told me to send it to you with his ack.
Thanks in ad
AIL PROTECTED]>
L'ordine non e` che una configurazione particolare del caos.
Sun Dec 10 23:25:24 CET 2000
The NEC-DUART patch corrects a bug in Linux-2.2.14' serial driver
(file linux/drivers/char/serial.c). The chipset probe algorithm
doesn
In serial.c, it appears that unless do_autoconfig() is called through an
ioctl() call, the variable state->type, which is used to index into the
uart_config[] array, is not set, resulting in problems (I'm working with
a mips embedded board). Why not set info->type from ssta
70 matches
Mail list logo