[PATCH] tty: mxser: fix usage of opmode_ioaddr
From: Matwey V. Kornilov
mxser_port->opmode_ioaddr is initialized only for MOXA_MUST_MU860_HWID
chips, but no precautions have been undertaken to prevent reading and
writing to undefined port number.
Signed-off-by: Matwey V. Kornilov
---
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 71d6eb2..f97b196 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -1618,8 +1618,12 @@ static int mxser_ioctl_special(unsigned int cmd, void
__user *argp)
if (ip->type == PORT_16550A)
me->fifo[p] = 1;
- opmode = inb(ip->opmode_ioaddr)>>((p % 4) * 2);
- opmode &= OP_MODE_MASK;
+ if (ip->board->chip_flag ==
MOXA_MUST_MU860_HWID) {
+ opmode = inb(ip->opmode_ioaddr)>>((p %
4) * 2);
+ opmode &= OP_MODE_MASK;
+ } else {
+ opmode = RS232_MODE;
+ }
me->iftype[p] = opmode;
mutex_unlock(&port->mutex);
}
@@ -1670,6 +1674,9 @@ static int mxser_ioctl(struct tty_struct *tty,
return mxser_ioctl_special(cmd, argp);
if (cmd == MOXA_SET_OP_MODE || cmd == MOXA_GET_OP_MODE) {
+ if (info->board->chip_flag != MOXA_MUST_MU860_HWID)
+ return -EFAULT;
+
int p;
unsigned long opmode;
static unsigned char ModeMask[] = { 0xfc, 0xf3, 0xcf, 0x3f };
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tty: mxser: Fix build warning introduced by dfc7b837c7f9 (Re: linux-next: build warning after merge of the tty.current tree)
From: Matwey V. Kornilov
Fix build warning at mxser.c introduced by dfc7b837c7f9
Signed-off-by: Matwey V. Kornilov
---
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index f97b196..4c4a236 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -1674,15 +1674,15 @@ static int mxser_ioctl(struct tty_struct *tty,
return mxser_ioctl_special(cmd, argp);
if (cmd == MOXA_SET_OP_MODE || cmd == MOXA_GET_OP_MODE) {
- if (info->board->chip_flag != MOXA_MUST_MU860_HWID)
- return -EFAULT;
-
int p;
unsigned long opmode;
static unsigned char ModeMask[] = { 0xfc, 0xf3, 0xcf, 0x3f };
int shiftbit;
unsigned char val, mask;
+ if (info->board->chip_flag != MOXA_MUST_MU860_HWID)
+ return -EFAULT;
+
p = tty->index % 4;
if (cmd == MOXA_SET_OP_MODE) {
if (get_user(opmode, (int __user *) argp))
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: cp210x new Vendor/Device IDs
From: Matwey V. Kornilov
This patch adds support for the Lake Shore Cryotronics devices to
the CP210x driver.
Signed-off-by: Matwey V. Kornilov
---
These lines are ported from cp210x driver distributed by Lake Shore web site:
http://www.lakeshore.com/Documents/Lake%20Shore%20cp210x-3.0.0.tar.gz
and licensed under the terms of GPLv2.
Moreover, I've tested this changes with Lake Shore 335 in my labs.
This patch is based on linux/kernel/git/gregkh/usb.git tree.
p.s Sorry for 80-column overflow, but I don't know how to format this comments
more concinnous.
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index edc0f0d..67088ce 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -150,6 +150,25 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
{ USB_DEVICE(0x1E29, 0x0102) }, /* Festo CPX-USB */
{ USB_DEVICE(0x1E29, 0x0501) }, /* Festo CMSP */
+ { USB_DEVICE(0x1FB9, 0x0100) }, /* Lake Shore Model 121 Current Source
*/
+ { USB_DEVICE(0x1FB9, 0x0200) }, /* Lake Shore Model 218A Temperature
Monitor */
+ { USB_DEVICE(0x1FB9, 0x0201) }, /* Lake Shore Model 219 Temperature
Monitor */
+ { USB_DEVICE(0x1FB9, 0x0202) }, /* Lake Shore Model 233 Temperature
Transmitter */
+ { USB_DEVICE(0x1FB9, 0x0203) }, /* Lake Shore Model 235 Temperature
Transmitter */
+ { USB_DEVICE(0x1FB9, 0x0300) }, /* Lake Shore Model 335 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0301) }, /* Lake Shore Model 336 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0302) }, /* Lake Shore Model 350 Temperature
Controller */
+ { USB_DEVICE(0x1FB9, 0x0303) }, /* Lake Shore Model 371 AC Bridge */
+ { USB_DEVICE(0x1FB9, 0x0400) }, /* Lake Shore Model 411 Handheld
Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0401) }, /* Lake Shore Model 425 Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0402) }, /* Lake Shore Model 455A Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0403) }, /* Lake Shore Model 475A Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0404) }, /* Lake Shore Model 465 Three Axis
Gaussmeter */
+ { USB_DEVICE(0x1FB9, 0x0600) }, /* Lake Shore Model 625A
Superconducting MPS */
+ { USB_DEVICE(0x1FB9, 0x0601) }, /* Lake Shore Model 642A Magnet Power
Supply */
+ { USB_DEVICE(0x1FB9, 0x0602) }, /* Lake Shore Model 648 Magnet Power
Supply */
+ { USB_DEVICE(0x1FB9, 0x0700) }, /* Lake Shore Model 737 VSM Controller
*/
+ { USB_DEVICE(0x1FB9, 0x0701) }, /* Lake Shore Model 776 Hall Matrix */
{ USB_DEVICE(0x3195, 0xF190) }, /* Link Instruments MSO-19 */
{ USB_DEVICE(0x3195, 0xF280) }, /* Link Instruments MSO-28 */
{ USB_DEVICE(0x3195, 0xF281) }, /* Link Instruments MSO-28 */
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: musb: musb_host: Introduce postponed URB giveback
Hi Bin,
I've just checked that the issue is still present in 4.13.10.
2017-04-27 13:20 GMT+03:00 Matwey V. Kornilov :
> This commit changes the order of actions undertaken in
> musb_advance_schedule() in order to overcome issue with broken
> isochronous transfer [1].
>
> There is no harm to split musb_giveback into two pieces. The first
> unlinks finished urb, the second givebacks it. The issue here that
> givebacking may be quite time-consuming due to urb->complete() call.
> As it happens in case of pwc-driven web cameras. It may take about 0.5
> ms to call __musb_giveback() that calls urb->callback() internally.
> Under specific circumstances setting MUSB_RXCSR_H_REQPKT in subsequent
> musb_start_urb() for the next urb will be too late to produce physical
> IN packet. Since auto req is not used by this module the exchange
> would be as the following:
>
> [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN : 4.5
> [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0: [skipped]
> [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN : 4.5
> [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0: 00 00
>
> It is known that missed IN in isochronous mode makes some
> perepherial broken. For instance, pwc-driven or uvc-driven
> web cameras.
> In order to workaround this issue we postpone calling
> urb->callback() after setting MUSB_RXCSR_H_REQPKT for the
> next urb if there is the next urb pending in queue.
>
> [1] https://www.spinics.net/lists/linux-usb/msg145747.html
>
> Fixes: f551e1352983 ("Revert "usb: musb: musb_host: Enable HCD_BH flag to
> handle urb return in bottom half"")
> Signed-off-by: Matwey V. Kornilov
> ---
> drivers/usb/musb/musb_host.c | 54
> +---
> 1 file changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> index ac3a4952abb4..b590c2555dab 100644
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -299,19 +299,24 @@ musb_start_urb(struct musb *musb, int is_in, struct
> musb_qh *qh)
> }
> }
>
> -/* Context: caller owns controller lock, IRQs are blocked */
> -static void musb_giveback(struct musb *musb, struct urb *urb, int status)
> +static void __musb_giveback(struct musb *musb, struct urb *urb, int status)
> __releases(musb->lock)
> __acquires(musb->lock)
> {
> - trace_musb_urb_gb(musb, urb);
> -
> - usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
> spin_unlock(&musb->lock);
> usb_hcd_giveback_urb(musb->hcd, urb, status);
> spin_lock(&musb->lock);
> }
>
> +/* Context: caller owns controller lock, IRQs are blocked */
> +static void musb_giveback(struct musb *musb, struct urb *urb, int status)
> +{
> + trace_musb_urb_gb(musb, urb);
> +
> + usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
> + __musb_giveback(musb, urb, status);
> +}
> +
> /* For bulk/interrupt endpoints only */
> static inline void musb_save_toggle(struct musb_qh *qh, int is_in,
> struct urb *urb)
> @@ -346,6 +351,7 @@ static void musb_advance_schedule(struct musb *musb,
> struct urb *urb,
> struct musb_hw_ep *ep = qh->hw_ep;
> int ready = qh->is_ready;
> int status;
> + int postponed_giveback = 0;
>
> status = (urb->status == -EINPROGRESS) ? 0 : urb->status;
>
> @@ -361,9 +367,35 @@ static void musb_advance_schedule(struct musb *musb,
> struct urb *urb,
> break;
> }
>
> - qh->is_ready = 0;
> - musb_giveback(musb, urb, status);
> - qh->is_ready = ready;
> + usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
> +
> + /* It may take about 0.5 ms to call __musb_giveback() that
> +* calls urb->callback() internally. Under specific circumstances
> +* setting MUSB_RXCSR_H_REQPKT in subsequent musb_start_urb() for the
> +* next urb will be too late to produce physical IN packet. Since
> +* auto req is not used by this module the exchange would be as the
> +* following:
> +*
> +* [] 7.220456 d= 0.000997 [182 + 3.667] [ 3] IN :
> 4.5
> +* [T ] 7.220459 d= 0.03 [182 + 7.000] [800] DATA0:
> [skipped]
> +* [] 7.222456 d= 0.001997 [184 + 3.667] [ 3] IN :
> 4.5
> +* [] 7.222459 d= 0.03 [184 + 7.000] [ 3] DATA0:
> 00 00
> +*
> +
Re: [PATCH v5 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
вт, 21 авг. 2018 г. в 20:06, Matwey V. Kornilov :
>
> DMA cocherency slows the transfer down on systems without hardware
> coherent DMA.
> Instead we use noncocherent DMA memory and explicit sync at data receive
> handler.
>
> Based on previous commit the following performance benchmarks have been
> carried out. Average memcpy() data transfer rate (rate) and handler
> completion time (time) have been measured when running video stream at
> 640x480 resolution at 10fps.
>
> x86_64 based system (Intel Core i5-3470). This platform has hardware
> coherent DMA support and proposed change doesn't make big difference here.
>
> * kmalloc:rate = (2.0 +- 0.4) GBps
>time = (5.0 +- 3.0) usec
> * usb_alloc_coherent: rate = (3.4 +- 1.2) GBps
>time = (3.5 +- 3.0) usec
>
> We see that the measurements agree within error ranges in this case.
> So theoretically predicted performance downgrade cannot be reliably
> measured here.
>
> armv7l based system (TI AM335x BeagleBone Black @ 300MHz). This platform
> has no hardware coherent DMA support. DMA coherence is implemented via
> disabled page caching that slows down memcpy() due to memory controller
> behaviour.
>
> * kmalloc:rate = (114 +- 5) MBps
>time = (84 +- 4) usec
> * usb_alloc_coherent: rate = (28.1 +- 0.1) MBps
>time = (341 +- 2) usec
>
> Note, that quantative difference leads (this commit leads to 4 times
> acceleration) to qualitative behavior change in this case. As it was
> stated before, the video stream cannot be successfully received at AM335x
> platforms with MUSB based USB host controller due to performance issues
> [1].
>
> [1] https://www.spinics.net/lists/linux-usb/msg165735.html
>
> Signed-off-by: Matwey V. Kornilov
Ping
> ---
> drivers/media/usb/pwc/pwc-if.c | 57
> --
> 1 file changed, 44 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
> index 72d2897a4b9f..1360722ab423 100644
> --- a/drivers/media/usb/pwc/pwc-if.c
> +++ b/drivers/media/usb/pwc/pwc-if.c
> @@ -159,6 +159,32 @@ static const struct video_device pwc_template = {
> /***/
> /* Private functions */
>
> +static void *pwc_alloc_urb_buffer(struct device *dev,
> + size_t size, dma_addr_t *dma_handle)
> +{
> + void *buffer = kmalloc(size, GFP_KERNEL);
> +
> + if (!buffer)
> + return NULL;
> +
> + *dma_handle = dma_map_single(dev, buffer, size, DMA_FROM_DEVICE);
> + if (dma_mapping_error(dev, *dma_handle)) {
> + kfree(buffer);
> + return NULL;
> + }
> +
> + return buffer;
> +}
> +
> +static void pwc_free_urb_buffer(struct device *dev,
> + size_t size,
> + void *buffer,
> + dma_addr_t dma_handle)
> +{
> + dma_unmap_single(dev, dma_handle, size, DMA_FROM_DEVICE);
> + kfree(buffer);
> +}
> +
> static struct pwc_frame_buf *pwc_get_next_fill_buf(struct pwc_device *pdev)
> {
> unsigned long flags = 0;
> @@ -306,6 +332,11 @@ static void pwc_isoc_handler(struct urb *urb)
> /* Reset ISOC error counter. We did get here, after all. */
> pdev->visoc_errors = 0;
>
> + dma_sync_single_for_cpu(&urb->dev->dev,
> + urb->transfer_dma,
> + urb->transfer_buffer_length,
> + DMA_FROM_DEVICE);
> +
> /* vsync: 0 = don't copy data
> 1 = sync-hunt
> 2 = synched
> @@ -428,16 +459,15 @@ static int pwc_isoc_init(struct pwc_device *pdev)
> urb->dev = udev;
> urb->pipe = usb_rcvisocpipe(udev, pdev->vendpoint);
> urb->transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
> - urb->transfer_buffer = usb_alloc_coherent(udev,
> - ISO_BUFFER_SIZE,
> - GFP_KERNEL,
> - &urb->transfer_dma);
> + urb->transfer_buffer_length = ISO_BUFFER_SIZE;
> + urb->transfer_buffer = pwc_alloc_urb_buffer(&udev->dev,
> +
> urb->transfer_buffer_length,
> +
Re: [PATCH v4 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
2018-08-17 20:44 GMT+03:00 Matwey V. Kornilov : > пт, 10 авг. 2018 г. в 17:27, Alan Stern : >> >> On Fri, 10 Aug 2018, Laurent Pinchart wrote: >> >> > > > Aren't you're missing a dma_sync_single_for_device() call before >> > > > submitting the URB ? IIRC that's required for correct operation of the >> > > > DMA >> > > > mapping API on some platforms, depending on the cache architecture. The >> > > > additional sync can affect performances, so it would be useful to >> > > > re-run >> > > > the perf test. >> > > >> > > This was already discussed: >> > > >> > > https://lkml.org/lkml/2018/7/23/1051 >> > > >> > > I rely on Alan's reply: >> > > >> > > > According to Documentation/DMA-API-HOWTO.txt, the CPU should not write >> > > > to a DMA_FROM_DEVICE-mapped area, so dma_sync_single_for_device() is >> > > > not needed. >> > >> > I fully agree that the CPU should not write to the buffer. However, I think >> > the sync call is still needed. It's been a long time since I touched this >> > area, but IIRC, some cache architectures (VIVT ?) require both cache clean >> > before the transfer and cache invalidation after the transfer. On platforms >> > where no cache management operation is needed before the transfer in the >> > DMA_FROM_DEVICE direction, the dma_sync_*_for_device() calls should be >> > no-ops >> > (and if they're not, it's a bug of the DMA mapping implementation). >> >> In general, I agree that the cache has to be clean before a transfer >> starts. This means some sort of mapping operation (like >> dma_sync_*_for-device) is indeed required at some point between the >> allocation and the first transfer. >> >> For subsequent transfers, however, the cache is already clean and it >> will remain clean because the CPU will not do any writes to the buffer. >> (Note: clean != empty. Rather, clean == !dirty.) Therefore transfers >> following the first should not need any dma_sync_*_for_device. >> >> If you don't accept this reasoning then you should ask the people who >> wrote DMA-API-HOWTO.txt. They certainly will know more about this >> issue than I do. > > Laurent, > > I have not seen any data corruption or glitches without > dma_sync_single_for_device() on ARM and x86. > It takes additional ~20usec for dma_sync_single_for_device() to run on > ARM. So It would be great to ensure that we can reliable save another > 15% running time. DMA-API-HOWTO.txt has and example with my_card_interrupt_handler() function where it says that "CPU should not write to DMA_FROM_DEVICE-mapped area, so dma_sync_single_for_device() is not needed here." I've found that, for instance, drivers/crypto/caam/caamrng.c follows DMA-API-HOWTO.txt and don't use dma_sync_single_for_device() in the same case as we have in pwc. > >> >> Alan Stern >> > > > -- > With best regards, > Matwey V. Kornilov -- With best regards, Matwey V. Kornilov
Re: [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
2018-07-24 23:55 GMT+03:00 Alan Stern : > On Tue, 24 Jul 2018, Matwey V. Kornilov wrote: > >> 2018-07-23 21:57 GMT+03:00 Alan Stern : >> > On Mon, 23 Jul 2018, Matwey V. Kornilov wrote: >> > >> >> I've tried to strategies: >> >> >> >> 1) Use dma_unmap and dma_map inside the handler (I suppose this is >> >> similar to how USB core does when there is no URB_NO_TRANSFER_DMA_MAP) >> > >> > Yes. >> > >> >> 2) Use sync_cpu and sync_device inside the handler (and dma_map only >> >> once at memory allocation) >> >> >> >> It is interesting that dma_unmap/dma_map pair leads to the lower >> >> overhead (+1us) than sync_cpu/sync_device (+2us) at x86_64 platform. >> >> At armv7l platform using dma_unmap/dma_map leads to ~50 usec in the >> >> handler, and sync_cpu/sync_device - ~65 usec. >> >> >> >> However, I am not sure is it mandatory to call >> >> dma_sync_single_for_device for FROM_DEVICE direction? >> > >> > According to Documentation/DMA-API-HOWTO.txt, the CPU should not write >> > to a DMA_FROM_DEVICE-mapped area, so dma_sync_single_for_device() is >> > not needed. >> >> Well, I measured the following at armv7l. The handler execution time >> (URB_NO_TRANSFER_DMA_MAP is used for all cases): >> >> 1) coherent DMA: ~3000 usec (pwc is not functional) >> 2) explicit dma_unmap and dma_map in the handler: ~52 usec >> 3) explicit dma_sync_single_for_cpu (no dma_sync_single_for_device): ~56 usec >> >> So, I suppose that unfortunately Tomasz suggestion doesn't work. There >> is no performance improvement when dma_sync_single is used. >> >> At x86_64 the following happens: >> >> 1) coherent DMA: ~2 usec >> 2) explicit dma_unmap and dma_map in the handler: ~3.5 usec >> 3) explicit dma_sync_single_for_cpu (no dma_sync_single_for_device): ~4 usec >> >> So, whats to do next? Personally, I think that DMA streaming API >> introduces not so great overhead. >> Does anybody happy with turning to streaming DMA or I'll introduce >> module-level switch as Ezequiel suggested? > > How about using the dma_unmap and dma_map calls in the USB core? If > they add the same overhead as putting them in the handler, I think it > would be acceptable for x86_64. Sure, that is the simplest way to implement streaming API. > > It certainly is odd that the dma_sync_single APIs take longer than > simply mapping and unmapping. Well. I am surprised too. Probably, it is related to that only 9560 bytes are used for each URB. It is only three memory pages. > > Alan Stern > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
[PATCH v6 1/2] media: usb: pwc: Introduce TRACE_EVENTs for pwc_isoc_handler()
There were reports that PWC-based webcams don't work at some
embedded ARM platforms. [1] Isochronous transfer handler seems to
work too long leading to the issues in MUSB USB host subsystem.
Also note, that urb->giveback() handlers are still called with
disabled interrupts. In order to be able to measure performance of
PWC driver, traces are introduced in URB handler section.
[1] https://www.spinics.net/lists/linux-usb/msg165735.html
Signed-off-by: Matwey V. Kornilov
---
drivers/media/usb/pwc/pwc-if.c | 7 +
include/trace/events/pwc.h | 65 ++
2 files changed, 72 insertions(+)
create mode 100644 include/trace/events/pwc.h
diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
index 72704f4d5330..53c111bd5a22 100644
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -76,6 +76,9 @@
#include "pwc-dec23.h"
#include "pwc-dec1.h"
+#define CREATE_TRACE_POINTS
+#include
+
/* Function prototypes and driver templates */
/* hotplug device table support */
@@ -260,6 +263,8 @@ static void pwc_isoc_handler(struct urb *urb)
int i, fst, flen;
unsigned char *iso_buf = NULL;
+ trace_pwc_handler_enter(urb, pdev);
+
if (urb->status == -ENOENT || urb->status == -ECONNRESET ||
urb->status == -ESHUTDOWN) {
PWC_DEBUG_OPEN("URB (%p) unlinked %ssynchronously.\n",
@@ -348,6 +353,8 @@ static void pwc_isoc_handler(struct urb *urb)
}
handler_end:
+ trace_pwc_handler_exit(urb, pdev);
+
i = usb_submit_urb(urb, GFP_ATOMIC);
if (i != 0)
PWC_ERROR("Error (%d) re-submitting urb in
pwc_isoc_handler.\n", i);
diff --git a/include/trace/events/pwc.h b/include/trace/events/pwc.h
new file mode 100644
index ..a2da764a3b41
--- /dev/null
+++ b/include/trace/events/pwc.h
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#if !defined(_TRACE_PWC_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_PWC_H
+
+#include
+#include
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM pwc
+
+TRACE_EVENT(pwc_handler_enter,
+ TP_PROTO(struct urb *urb, struct pwc_device *pdev),
+ TP_ARGS(urb, pdev),
+ TP_STRUCT__entry(
+ __field(struct urb*, urb)
+ __field(struct pwc_frame_buf*, fbuf)
+ __field(int, urb__status)
+ __field(u32, urb__actual_length)
+ __field(int, fbuf__filled)
+ __string(name, pdev->v4l2_dev.name)
+ ),
+ TP_fast_assign(
+ __entry->urb = urb;
+ __entry->fbuf = pdev->fill_buf;
+ __entry->urb__status = urb->status;
+ __entry->urb__actual_length = urb->actual_length;
+ __entry->fbuf__filled = (pdev->fill_buf
+? pdev->fill_buf->filled : 0);
+ __assign_str(name, pdev->v4l2_dev.name);
+ ),
+ TP_printk("dev=%s (fbuf=%p filled=%d) urb=%p (status=%d
actual_length=%u)",
+ __get_str(name),
+ __entry->fbuf,
+ __entry->fbuf__filled,
+ __entry->urb,
+ __entry->urb__status,
+ __entry->urb__actual_length)
+);
+
+TRACE_EVENT(pwc_handler_exit,
+ TP_PROTO(struct urb *urb, struct pwc_device *pdev),
+ TP_ARGS(urb, pdev),
+ TP_STRUCT__entry(
+ __field(struct urb*, urb)
+ __field(struct pwc_frame_buf*, fbuf)
+ __field(int, fbuf__filled)
+ __string(name, pdev->v4l2_dev.name)
+ ),
+ TP_fast_assign(
+ __entry->urb = urb;
+ __entry->fbuf = pdev->fill_buf;
+ __entry->fbuf__filled = pdev->fill_buf->filled;
+ __assign_str(name, pdev->v4l2_dev.name);
+ ),
+ TP_printk(" dev=%s (fbuf=%p filled=%d) urb=%p",
+ __get_str(name),
+ __entry->fbuf,
+ __entry->fbuf__filled,
+ __entry->urb)
+);
+
+#endif /* _TRACE_PWC_H */
+
+/* This part must be outside protection */
+#include
--
2.16.4
Re: [PATCH v6 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
пт, 30 нояб. 2018 г. в 15:20, Matwey V. Kornilov :
>
> ср, 21 нояб. 2018 г. в 21:15, Matwey V. Kornilov :
> >
> > пт, 9 нояб. 2018 г. в 22:03, Matwey V. Kornilov :
> > >
> > > DMA cocherency slows the transfer down on systems without hardware
> > > coherent DMA.
> > > Instead we use noncocherent DMA memory and explicit sync at data receive
> > > handler.
> > >
> > > Based on previous commit the following performance benchmarks have been
> > > carried out. Average memcpy() data transfer rate (rate) and handler
> > > completion time (time) have been measured when running video stream at
> > > 640x480 resolution at 10fps.
> > >
> > > x86_64 based system (Intel Core i5-3470). This platform has hardware
> > > coherent DMA support and proposed change doesn't make big difference here.
> > >
> > > * kmalloc:rate = (2.0 +- 0.4) GBps
> > >time = (5.0 +- 3.0) usec
> > > * usb_alloc_coherent: rate = (3.4 +- 1.2) GBps
> > >time = (3.5 +- 3.0) usec
> > >
> > > We see that the measurements agree within error ranges in this case.
> > > So theoretically predicted performance downgrade cannot be reliably
> > > measured here.
> > >
> > > armv7l based system (TI AM335x BeagleBone Black @ 300MHz). This platform
> > > has no hardware coherent DMA support. DMA coherence is implemented via
> > > disabled page caching that slows down memcpy() due to memory controller
> > > behaviour.
> > >
> > > * kmalloc:rate = ( 94 +- 4) MBps
> > >time = (101 +- 4) usec
> > > * usb_alloc_coherent: rate = (28.1 +- 0.1) MBps
> > >time = (341 +- 2) usec
> > >
> > > Note, that quantative difference leads (this commit leads to 3.3 times
> > > acceleration) to qualitative behavior change in this case. As it was
> > > stated before, the video stream cannot be successfully received at AM335x
> > > platforms with MUSB based USB host controller due to performance issues
> > > [1].
> > >
> > > [1] https://www.spinics.net/lists/linux-usb/msg165735.html
> > >
> > > Signed-off-by: Matwey V. Kornilov
> >
> > Ping
>
> Ping
Ping
>
> >
> > > ---
> > > drivers/media/usb/pwc/pwc-if.c | 62
> > > +-
> > > 1 file changed, 49 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/media/usb/pwc/pwc-if.c
> > > b/drivers/media/usb/pwc/pwc-if.c
> > > index 53c111bd5a22..a81fb319b339 100644
> > > --- a/drivers/media/usb/pwc/pwc-if.c
> > > +++ b/drivers/media/usb/pwc/pwc-if.c
> > > @@ -159,6 +159,32 @@ static const struct video_device pwc_template = {
> > >
> > > /***/
> > > /* Private functions */
> > >
> > > +static void *pwc_alloc_urb_buffer(struct device *dev,
> > > + size_t size, dma_addr_t *dma_handle)
> > > +{
> > > + void *buffer = kmalloc(size, GFP_KERNEL);
> > > +
> > > + if (!buffer)
> > > + return NULL;
> > > +
> > > + *dma_handle = dma_map_single(dev, buffer, size, DMA_FROM_DEVICE);
> > > + if (dma_mapping_error(dev, *dma_handle)) {
> > > + kfree(buffer);
> > > + return NULL;
> > > + }
> > > +
> > > + return buffer;
> > > +}
> > > +
> > > +static void pwc_free_urb_buffer(struct device *dev,
> > > + size_t size,
> > > + void *buffer,
> > > + dma_addr_t dma_handle)
> > > +{
> > > + dma_unmap_single(dev, dma_handle, size, DMA_FROM_DEVICE);
> > > + kfree(buffer);
> > > +}
> > > +
> > > static struct pwc_frame_buf *pwc_get_next_fill_buf(struct pwc_device
> > > *pdev)
> > > {
> > > unsigned long flags = 0;
> > > @@ -306,6 +332,11 @@ static void pwc_isoc_handler(struct urb *urb)
> > > /* Reset ISOC error counter. We did get here, after all. */
> > > pdev->visoc_errors = 0;
> > >
> > > + dma_sync_single_for_cpu(&urb->dev->dev,
> > > + urb->transfer_dma,
&
Re: [PATCH v6 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
ср, 12 дек. 2018 г. в 17:01, Steven Rostedt : > > On Wed, 12 Dec 2018 08:56:22 -0500 > Steven Rostedt wrote: > > > Can someone please take this patch or at least say what's wrong with it > > if you have a problem? > > > > Matwey has been patiently pinging us once every other week for over a > > month asking for a reply. I've already given my Reviewed-by from a > > tracing perspective. > > > > Ignoring patches is not a friendly gesture. > > > > Nevermind, it appears that v5 is still under discussion. > > Matwey, does v6 address the comments made in v5? Hi, v6 addresses the comments made by Laurent Pinchart on Oct, 31: https://www.spinics.net/lists/linux-media/msg142216.html namely, dma_sync_single_for_device() is introduced in the proper place > > -- Steve -- With best regards, Matwey V. Kornilov
Re: [PATCH v6 0/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
ср, 12 дек. 2018 г. в 20:41, Ezequiel Garcia : > > On Wed, 12 Dec 2018 at 14:27, Laurent Pinchart > wrote: > > > > Hi Matwey, > > > > Thank you for the patches. > > > > For the whole series, > > > > Reviewed-by: Laurent Pinchart > > > > Thanks Laurent. > > Matwey, given your detailed analysis of this issue, > and given you have pwc hardware to test, I think > you should consider co-maintaining this driver. > Well, It would be great if I could help. Is there some guide how to apply? > Thanks, > -- > Ezequiel García, VanguardiaSur > www.vanguardiasur.com.ar -- With best regards, Matwey V. Kornilov
[PATCH] uio: pruss: Drop depends on ARCH_DAVINCI_DA850 from config
mach-dependent stuff has been removed by 2eb2478d471e45e1d0c8bb3defbf82bf7204e13d So, there is no need to keep depends on ARCH_DAVINCI_DA850 Signed-off-by: Matwey V. Kornilov --- drivers/uio/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 8a15c32..9c9178a 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -126,7 +126,6 @@ config UIO_FSL_ELBC_GPCM_NETX5152 config UIO_PRUSS tristate "Texas Instruments PRUSS driver" - depends on ARCH_DAVINCI_DA850 select GENERIC_ALLOCATOR help PRUSS driver for OMAPL138/DA850/AM18XX devices -- 2.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 1/2] uio: pruss: Include
uio_pruss references SZ_16K and SZ_256K defines, but linux/sizes.h is not included. Signed-off-by: Matwey V. Kornilov --- Changes from v1: - Add uio: pruss: Include patch to allow build on all architectures drivers/uio/uio_pruss.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c index 818735b..ca9e2fa 100644 --- a/drivers/uio/uio_pruss.c +++ b/drivers/uio/uio_pruss.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include -- 2.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 2/2] uio: pruss: Drop depends on ARCH_DAVINCI_DA850 from config
mach-dependant stuff has been removed by 2eb2478d471e45e1d0c8bb3defbf82bf7204e13d There is no need to keep depends on ARCH_DAVINCI_DA850 Signed-off-by: Matwey V. Kornilov --- drivers/uio/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 8a15c32..9c9178a 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -126,7 +126,6 @@ config UIO_FSL_ELBC_GPCM_NETX5152 config UIO_PRUSS tristate "Texas Instruments PRUSS driver" - depends on ARCH_DAVINCI_DA850 select GENERIC_ALLOCATOR help PRUSS driver for OMAPL138/DA850/AM18XX devices -- 2.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 2/2] uio: pruss: Drop depends on ARCH_DAVINCI_DA850 from config
2015-06-06 19:11 GMT+03:00 Richard Weinberger : > On Sat, Jun 6, 2015 at 5:49 PM, Matwey V. Kornilov wrote: >> mach-dependant stuff has been removed by >>2eb2478d471e45e1d0c8bb3defbf82bf7204e13d >> >> There is no need to keep >> depends on ARCH_DAVINCI_DA850 > > The driver dependencies are still broken. > It needs ioremap(), hence make it depend on HAS_IOMEM. > Otherwise you break the build for UML and some s390 variants > which do not have io memory. Thank you, I will go redo. > > -- > Thanks, > //richard > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/4] uio: pruss: Include
uio_pruss references SZ_16K and SZ_256K defines, but linux/sizes.h is not included. Signed-off-by: Matwey V. Kornilov Changes from v1: - Fix build for platforms without ioremap - Fix build for x86_64 --- drivers/uio/uio_pruss.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c index 818735b..ca9e2fa 100644 --- a/drivers/uio/uio_pruss.c +++ b/drivers/uio/uio_pruss.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include -- 2.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/4] uio: pruss: Add CONFIG_HAS_IOMEM dependence
uio_pruss uses io memory, that should be explicitly depend on it Signed-off-by: Matwey V. Kornilov --- drivers/uio/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 8a15c32..91d9f2b 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -128,6 +128,7 @@ config UIO_PRUSS tristate "Texas Instruments PRUSS driver" depends on ARCH_DAVINCI_DA850 select GENERIC_ALLOCATOR + depends on HAS_IOMEM help PRUSS driver for OMAPL138/DA850/AM18XX devices PRUSS driver requires user space components, examples and user space -- 2.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/4] uio: pruss: Include
uio_pruss uses ioremap which is in linux/vmalloc.h according to LDD3 sec. 8.3 Signed-off-by: Matwey V. Kornilov --- drivers/uio/uio_pruss.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c index ca9e2fa..5ae7c31 100644 --- a/drivers/uio/uio_pruss.c +++ b/drivers/uio/uio_pruss.c @@ -27,6 +27,7 @@ #include #include #include +#include #define DRV_NAME "pruss_uio" #define DRV_VERSION "1.0" -- 2.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/4] uio: pruss: Drop depends on ARCH_DAVINCI_DA850 from config
mach-dependant stuff has been removed by 2eb2478d471e45e1d0c8bb3defbf82bf7204e13d There is no need to keep depends on ARCH_DAVINCI_DA850 Signed-off-by: Matwey V. Kornilov --- drivers/uio/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 91d9f2b..48fb1d9 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -126,7 +126,6 @@ config UIO_FSL_ELBC_GPCM_NETX5152 config UIO_PRUSS tristate "Texas Instruments PRUSS driver" - depends on ARCH_DAVINCI_DA850 select GENERIC_ALLOCATOR depends on HAS_IOMEM help -- 2.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/3] uio: pruss: Include
uio_pruss references SZ_16K and SZ_256K defines, but linux/sizes.h is not included. Signed-off-by: Matwey V. Kornilov --- Changes from v3: - Prettify commit messages - Drop unneeded "uio: pruss: Include " Changes from v1: - Fix build for platforms without ioremap - Fix build for x86_64 drivers/uio/uio_pruss.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/uio/uio_pruss.c b/drivers/uio/uio_pruss.c index 818735b..ca9e2fa 100644 --- a/drivers/uio/uio_pruss.c +++ b/drivers/uio/uio_pruss.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include -- 2.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/3] uio: pruss: Add CONFIG_HAS_IOMEM dependence
uio_pruss uses io memory, that should be explicitly depend on it Signed-off-by: Matwey V. Kornilov --- drivers/uio/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 8a15c32..91d9f2b 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -128,6 +128,7 @@ config UIO_PRUSS tristate "Texas Instruments PRUSS driver" depends on ARCH_DAVINCI_DA850 select GENERIC_ALLOCATOR + depends on HAS_IOMEM help PRUSS driver for OMAPL138/DA850/AM18XX devices PRUSS driver requires user space components, examples and user space -- 2.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/3] uio: pruss: Drop depends on ARCH_DAVINCI_DA850 from config
mach-dependant stuff has been removed by
2eb2478d471e ("uio: uio_pruss: replace private SRAM API with genalloc")
There is no need to keep
depends on ARCH_DAVINCI_DA850
Signed-off-by: Matwey V. Kornilov
---
drivers/uio/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 91d9f2b..48fb1d9 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -126,7 +126,6 @@ config UIO_FSL_ELBC_GPCM_NETX5152
config UIO_PRUSS
tristate "Texas Instruments PRUSS driver"
- depends on ARCH_DAVINCI_DA850
select GENERIC_ALLOCATOR
depends on HAS_IOMEM
help
--
2.1.4
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] serial: 8250: Add 485 emulation to 8250_dw.
2018-06-04 13:12 GMT+03:00 Andy Shevchenko : > On Fri, 2018-06-01 at 14:40 +0200, Giulio Benetti wrote: >> Need to handle rs485 with 8250_dw port. >> >> Use existing em485 emulation layer for 8250 taking care to fix some >> bug >> and taking care especially of RTS_AFTER_SEND case. >> > > I don't see in Cc list author of rs485 code, who might be interested in > this. > > So, added him here. > Hi, Andy Nice to see you there. I will look through the code later. I always thought that DW has its own hardware rs485 support. >> Giulio Benetti (8): >> serial: 8250_dw: add em485 support >> serial: 8250_dw: allow enable rs485 at boot time >> serial: 8250: Copy em485 from port to real port. >> serial: 8250: Handle case port doesn't have TEMT interrupt using >> em485. >> serial: 8250_dw: treat rpm suspend with -EBUSY if RS485 ON and >> RTS_AFTER_SEND >> serial: 8250: Copy mctrl when register port. >> serial: 8250: Make em485_rts_after_send() set mctrl according to rts >> state. >> serial: core: Mask mctrl with TIOCM_RTS too if rs485 on and >> RTS_AFTER_SEND set. >> >> drivers/tty/serial/8250/8250.h | 2 +- >> drivers/tty/serial/8250/8250_core.c | 2 ++ >> drivers/tty/serial/8250/8250_dw.c | 41 >> - >> drivers/tty/serial/8250/8250_omap.c | 2 +- >> drivers/tty/serial/8250/8250_port.c | 33 --- >> drivers/tty/serial/serial_core.c| 12 ++++++++- >> include/linux/serial_8250.h | 1 + >> 7 files changed, 79 insertions(+), 14 deletions(-) >> > > -- > Andy Shevchenko > Intel Finland Oy > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
Re: [PATCH 4/8] serial: 8250: Handle case port doesn't have TEMT interrupt using em485.
01.06.2018 15:40, Giulio Benetti пишет:
> Some 8250 ports only have TEMT interrupt, so current implementation
> can't work for ports without it. The only chance to make it work is to
> loop-read on LSR register.
>
> With NO TEMT interrupt check if both TEMT and THRE are set looping on
> LSR register.
>
> Signed-off-by: Giulio Benetti
> ---
> drivers/tty/serial/8250/8250.h | 2 +-
> drivers/tty/serial/8250/8250_dw.c | 2 +-
> drivers/tty/serial/8250/8250_omap.c | 2 +-
> drivers/tty/serial/8250/8250_port.c | 26 ++
> include/linux/serial_8250.h | 1 +
> 5 files changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
> index ebfb0bd5bef5..5c6ae5f69432 100644
> --- a/drivers/tty/serial/8250/8250.h
> +++ b/drivers/tty/serial/8250/8250.h
> @@ -136,7 +136,7 @@ void serial8250_rpm_put(struct uart_8250_port *p);
> void serial8250_rpm_get_tx(struct uart_8250_port *p);
> void serial8250_rpm_put_tx(struct uart_8250_port *p);
>
> -int serial8250_em485_init(struct uart_8250_port *p);
> +int serial8250_em485_init(struct uart_8250_port *p, bool has_temt_isr);
> void serial8250_em485_destroy(struct uart_8250_port *p);
>
> static inline void serial8250_out_MCR(struct uart_8250_port *up, int value)
> diff --git a/drivers/tty/serial/8250/8250_dw.c
> b/drivers/tty/serial/8250/8250_dw.c
> index 0f8b4da03d4e..888280ff5451 100644
> --- a/drivers/tty/serial/8250/8250_dw.c
> +++ b/drivers/tty/serial/8250/8250_dw.c
> @@ -330,7 +330,7 @@ static int dw8250_rs485_config(struct uart_port *p,
>* are idempotent
>*/
> if (rs485->flags & SER_RS485_ENABLED) {
> - int ret = serial8250_em485_init(up);
> + int ret = serial8250_em485_init(up, false);
>
> if (ret) {
> rs485->flags &= ~SER_RS485_ENABLED;
> diff --git a/drivers/tty/serial/8250/8250_omap.c
> b/drivers/tty/serial/8250/8250_omap.c
> index 624b501fd253..ab483c8b30c8 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -725,7 +725,7 @@ static int omap_8250_rs485_config(struct uart_port *port,
>* are idempotent
>*/
> if (rs485->flags & SER_RS485_ENABLED) {
> - int ret = serial8250_em485_init(up);
> + int ret = serial8250_em485_init(up, true);
>
> if (ret) {
> rs485->flags &= ~SER_RS485_ENABLED;
> diff --git a/drivers/tty/serial/8250/8250_port.c
> b/drivers/tty/serial/8250/8250_port.c
> index 95833cbc4338..e14badbbf181 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -599,15 +599,16 @@ EXPORT_SYMBOL_GPL(serial8250_rpm_put);
> /**
> * serial8250_em485_init() - put uart_8250_port into rs485 emulating
> * @p: uart_8250_port port instance
> + * @p: bool specify if 8250 port has TEMT interrupt or not
> *
> * The function is used to start rs485 software emulating on the
> * &struct uart_8250_port* @p. Namely, RTS is switched before/after
> * transmission. The function is idempotent, so it is safe to call it
> * multiple times.
> *
> - * The caller MUST enable interrupt on empty shift register before
> - * calling serial8250_em485_init(). This interrupt is not a part of
> - * 8250 standard, but implementation defined.
> + * If has_temt_isr is passed as true, the caller MUST enable interrupt
> + * on empty shift register before calling serial8250_em485_init().
> + * This interrupt is not a part of 8250 standard, but implementation
> defined.
> *
> * The function is supposed to be called from .rs485_config callback
> * or from any other callback protected with p->port.lock spinlock.
> @@ -616,7 +617,7 @@ EXPORT_SYMBOL_GPL(serial8250_rpm_put);
> *
> * Return 0 - success, -errno - otherwise
> */
> -int serial8250_em485_init(struct uart_8250_port *p)
> +int serial8250_em485_init(struct uart_8250_port *p, bool has_temt_isr)
> {
> if (p->em485)
> return 0;
> @@ -633,6 +634,7 @@ int serial8250_em485_init(struct uart_8250_port *p)
> p->em485->start_tx_timer.function = &serial8250_em485_handle_start_tx;
> p->em485->port = p;
> p->em485->active_timer = NULL;
> + p->em485->has_temt_isr = has_temt_isr;
> serial8250_em485_rts_after_send(p);
>
> return 0;
> @@ -1517,11 +1519,19 @@ static inline void __stop_tx(struct uart_8250_port *p)
> /*
>* To provide required timeing and allow FIFO transfer,
>* __stop_tx_rs485() must be called only when both FIFO and
> - * shift register are empty. It is for device driver to enable
> - * interrupt on TEMT.
> + * shift register are empty. If 8250 port supports it,
> + * it is for device driver to enable interrupt on TEMT.
> + * Otherwise must loop-read un
Re: [PATCH 4/8] serial: 8250: Handle case port doesn't have TEMT interrupt using em485.
2018-06-04 21:50 GMT+03:00 Giulio Benetti :
> Il 04/06/2018 19:40, Matwey V. Kornilov ha scritto:
>>
>> 01.06.2018 15:40, Giulio Benetti пишет:
>>>
>>> Some 8250 ports only have TEMT interrupt, so current implementation
>>> can't work for ports without it. The only chance to make it work is to
>>> loop-read on LSR register.
>>>
>>> With NO TEMT interrupt check if both TEMT and THRE are set looping on
>>> LSR register.
>>>
>>> Signed-off-by: Giulio Benetti
>>> ---
>>> drivers/tty/serial/8250/8250.h | 2 +-
>>> drivers/tty/serial/8250/8250_dw.c | 2 +-
>>> drivers/tty/serial/8250/8250_omap.c | 2 +-
>>> drivers/tty/serial/8250/8250_port.c | 26 ++
>>> include/linux/serial_8250.h | 1 +
>>> 5 files changed, 22 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/8250/8250.h
>>> b/drivers/tty/serial/8250/8250.h
>>> index ebfb0bd5bef5..5c6ae5f69432 100644
>>> --- a/drivers/tty/serial/8250/8250.h
>>> +++ b/drivers/tty/serial/8250/8250.h
>>> @@ -136,7 +136,7 @@ void serial8250_rpm_put(struct uart_8250_port *p);
>>> void serial8250_rpm_get_tx(struct uart_8250_port *p);
>>> void serial8250_rpm_put_tx(struct uart_8250_port *p);
>>> -int serial8250_em485_init(struct uart_8250_port *p);
>>> +int serial8250_em485_init(struct uart_8250_port *p, bool has_temt_isr);
>>> void serial8250_em485_destroy(struct uart_8250_port *p);
>>> static inline void serial8250_out_MCR(struct uart_8250_port *up, int
>>> value)
>>> diff --git a/drivers/tty/serial/8250/8250_dw.c
>>> b/drivers/tty/serial/8250/8250_dw.c
>>> index 0f8b4da03d4e..888280ff5451 100644
>>> --- a/drivers/tty/serial/8250/8250_dw.c
>>> +++ b/drivers/tty/serial/8250/8250_dw.c
>>> @@ -330,7 +330,7 @@ static int dw8250_rs485_config(struct uart_port *p,
>>> * are idempotent
>>> */
>>> if (rs485->flags & SER_RS485_ENABLED) {
>>> - int ret = serial8250_em485_init(up);
>>> + int ret = serial8250_em485_init(up, false);
>>> if (ret) {
>>> rs485->flags &= ~SER_RS485_ENABLED;
>>> diff --git a/drivers/tty/serial/8250/8250_omap.c
>>> b/drivers/tty/serial/8250/8250_omap.c
>>> index 624b501fd253..ab483c8b30c8 100644
>>> --- a/drivers/tty/serial/8250/8250_omap.c
>>> +++ b/drivers/tty/serial/8250/8250_omap.c
>>> @@ -725,7 +725,7 @@ static int omap_8250_rs485_config(struct uart_port
>>> *port,
>>> * are idempotent
>>> */
>>> if (rs485->flags & SER_RS485_ENABLED) {
>>> - int ret = serial8250_em485_init(up);
>>> + int ret = serial8250_em485_init(up, true);
>>> if (ret) {
>>> rs485->flags &= ~SER_RS485_ENABLED;
>>> diff --git a/drivers/tty/serial/8250/8250_port.c
>>> b/drivers/tty/serial/8250/8250_port.c
>>> index 95833cbc4338..e14badbbf181 100644
>>> --- a/drivers/tty/serial/8250/8250_port.c
>>> +++ b/drivers/tty/serial/8250/8250_port.c
>>> @@ -599,15 +599,16 @@ EXPORT_SYMBOL_GPL(serial8250_rpm_put);
>>> /**
>>>*serial8250_em485_init() - put uart_8250_port into rs485 emulating
>>>*@p: uart_8250_port port instance
>>> + * @p: bool specify if 8250 port has TEMT interrupt or not
>>>*
>>>*The function is used to start rs485 software emulating on the
>>>*&struct uart_8250_port* @p. Namely, RTS is switched before/after
>>>*transmission. The function is idempotent, so it is safe to call
>>> it
>>>*multiple times.
>>>*
>>> - * The caller MUST enable interrupt on empty shift register before
>>> - * calling serial8250_em485_init(). This interrupt is not a part of
>>> - * 8250 standard, but implementation defined.
>>> + * If has_temt_isr is passed as true, the caller MUST enable
>>> interrupt
>>> + * on empty shift register before calling serial8250_em485_init().
>>> + * This interrupt is not a part of 8250 standard, but implementation
>>> defined.
>>>*
>>>*The function is supposed to be called from .rs485_config callback
>>>*or from any other callback protected with p->port.lock spinlock.
>>> @@ -616,7 +617,7
Re: [PATCH 1/4] serial: 8250: Copy em485 from port to real port.
2018-06-06 16:11 GMT+03:00 Andy Shevchenko :
> On Wed, 2018-06-06 at 14:15 +0200, Giulio Benetti wrote:
>> Il 06/06/2018 13:56, Andy Shevchenko ha scritto:
>> > On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
>> > > em485 gets lost during
>> > >
>> > > Copy em485 to final uart port.
>> > >
>> >
>> > Is it needed at all?
>> >
>> > The individual driver decides either to use software emulation (and
>> > calls explicitly serial8250_em485_init() for that) or do HW assisted
>> > stuff.
>>
>> In 8250_dw.c, during probe(), I need to call dw8250_rs485_config()
>> against local struct uart_8250_port uart = {};
>> Inside serial8250_register_8250_port() not all uart fields are
>> copied(em485 too).
>> So after probe, em485 is NULL.
>>
>> Another way could be to call dw8250_rs485_config() against real uart
>> port, after calling serial8250_register_8250_port(),
>> would it make sense?
>
> Look at OMAP case closely. They have a callback to configure RS485 which
> is called in uart_set_rs485_config() which is called whenever user
> space does TIOCGRS485 IOCTL.
>
> So, it's completely driven by user space which makes sense by my
> opinion.
AFAIU, Giulio wants to add support for rs485-enabled-at-boot-time
device tree option (see bindings/serial/rs485.txt for reference).
I suppose it is only important for use-case when rs485 used as slave
(peripheral role).
>
> --
> Andy Shevchenko
> Intel Finland Oy
--
With best regards,
Matwey V. Kornilov
Re: [PATCH 1/4] serial: 8250: Copy em485 from port to real port.
2018-06-06 22:15 GMT+03:00 Giulio Benetti :
> Il 06/06/2018 20:55, Matwey V. Kornilov ha scritto:
>>
>> 2018-06-06 16:11 GMT+03:00 Andy Shevchenko
>> :
>>>
>>> On Wed, 2018-06-06 at 14:15 +0200, Giulio Benetti wrote:
>>>>
>>>> Il 06/06/2018 13:56, Andy Shevchenko ha scritto:
>>>>>
>>>>> On Wed, 2018-06-06 at 11:49 +0200, Giulio Benetti wrote:
>>>>>>
>>>>>> em485 gets lost during
>>>>>>
>>>>>> Copy em485 to final uart port.
>>>>>>
>>>>>
>>>>> Is it needed at all?
>>>>>
>>>>> The individual driver decides either to use software emulation (and
>>>>> calls explicitly serial8250_em485_init() for that) or do HW assisted
>>>>> stuff.
>>>>
>>>>
>>>> In 8250_dw.c, during probe(), I need to call dw8250_rs485_config()
>>>> against local struct uart_8250_port uart = {};
>>>> Inside serial8250_register_8250_port() not all uart fields are
>>>> copied(em485 too).
>>>> So after probe, em485 is NULL.
>>>>
>>>> Another way could be to call dw8250_rs485_config() against real uart
>>>> port, after calling serial8250_register_8250_port(),
>>>> would it make sense?
>>>
>>>
>>> Look at OMAP case closely. They have a callback to configure RS485 which
>>> is called in uart_set_rs485_config() which is called whenever user
>>> space does TIOCGRS485 IOCTL.
>>>
>>> So, it's completely driven by user space which makes sense by my
>>> opinion.
>>
>>
>> AFAIU, Giulio wants to add support for rs485-enabled-at-boot-time
>> device tree option (see bindings/serial/rs485.txt for reference).
>
>
> Yes, I want to add support for "rs485-enabled-at-boot-time" property,
> maybe I had to write better commit log and a cover letter. Sorry.
>
>> I suppose it is only important for use-case when rs485 used as slave
>> (peripheral role).
>
>
> It's important also for master, because RTS, if RTS_AFTER_SEND is set,
> remains not asserted(trasnmission) until userspace opens that serial port.
>
And it makes no sense, because how are you going to transmit and
receive not opening the port and not running an application?
It is master who transmits the data first. So, before all systems
going to work you have to open the port from userspace.
In case of slave this of course makes sense.
> Sorry again for not explaining myself well.
>
>
> --
> Giulio Benetti
> CTO
>
> MICRONOVA SRL
> Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
> Tel. 049/8931563 - Fax 049/8931346
> Cod.Fiscale - P.IVA 02663420285
> Capitale Sociale € 26.000 i.v.
> Iscritta al Reg. Imprese di Padova N. 02663420285
> Numero R.E.A. 258642
--
With best regards,
Matwey V. Kornilov
Re: [PATCH] usb: musb: Fix potential NULL dereference
сб, 26 янв. 2019 г. в 00:37, Alan Stern :
>
> On Fri, 25 Jan 2019, Bin Liu wrote:
>
> > On Thu, Jan 24, 2019 at 09:47:02PM +0300, Matwey V. Kornilov wrote:
> > > By the way, why do we need to store the qh in urb->hcpriv?
> > > qh can always be accessible through urb->ep->hcpriv
> > > Wouldn't it be better to drop entire urb->hcpriv usage?
> >
> > I am not sure why. The code is there since the first commit in a decade
> > ago. But I tend to agree with you.
> >
> > In a quick search for urb->hcpriv and urb->ep->hcpriv, based on the
> > usage in core/hcd.c, it seems to me that urb->hcpriv should not be
> > changed in each controller driver, but I see both have been used in most
> > controller drivers. I will leave this to others to educate me.
>
> In some of the older HCDs, urb->hcpriv != NULL is used to indicate that
> urb is on an endpoint queue. Perhaps that usage was copied.
>
> Alan Stern
>
Hi,
Thank you for the explanation. I think that It would be great to
document it somewhere. Such a purpose for variable named `hcpriv' is
not entirely obvious.
Now it is clear to me, why __usb_hcd_giveback_urb() sets urb->hcpriv to NULL.
Returning to my initial patch. I think that it is still valid, though
I admit that the commit message must be rewritten.
In this code path we successfully queued the new urb, so urb->hcpriv
should be NOT NULL indicating that the urb is queued according to Alan
explanation.
musb_urb_enqueue(), musb_host.c line 2345:
if (ret == 0) {
urb->hcpriv = qh;
/* FIXME set urb->start_frame for iso/intr, it's tested in
* musb_start_urb(), but otherwise only konicawc cares ...
*/
}
--
With best regards,
Matwey V. Kornilov
[PATCH v3] hwmon: lm75: Handle broken device nodes gracefully
There is a logical flaw in lm75_probe() function introduced in
commit e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
Note, that of_device_get_match_data() returns NULL when no match
is found. This is the case when OF node exists but has unknown
compatible line, while the module is still loaded via i2c
detection.
arch/powerpc/boot/dts/fsl/p2041rdb.dts:
lm75b@48 {
compatible = "nxp,lm75a";
reg = <0x48>;
};
In this case, the sensor is mistakenly considered as ADT75 variant.
Fixes: e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
Signed-off-by: Matwey V. Kornilov
---
Changes since v2:
* fixed typo in the message
* fixed brackets
drivers/hwmon/lm75.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index e447febd121a..53882c334a0d 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -561,10 +561,17 @@ static int lm75_probe(struct i2c_client *client)
int status, err;
enum lm75_type kind;
- if (client->dev.of_node)
- kind = (enum lm75_type)of_device_get_match_data(&client->dev);
- else
+ if (dev->of_node) {
+ const struct of_device_id *match =
+ of_match_device(dev->driver->of_match_table, dev);
+
+ if (!match)
+ return -ENODEV;
+
+ kind = (enum lm75_type)(match->data);
+ } else {
kind = i2c_match_id(lm75_ids, client)->driver_data;
+ }
if (!i2c_check_functionality(client->adapter,
I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA))
--
2.26.2
[PATCH] hwmon: lm75: Use zero lm75_type for lm75
There is a logical flaw in lm75_probe() function introduced in
e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
Note, that of_device_get_match_data() returns NULL when no match
found. This is the case when OF node exists but has unknown
compatible line, while the module is still loaded via i2c
detection.
arch/powerpc/boot/dts/fsl/p2041rdb.dts:
lm75b@48 {
compatible = "nxp,lm75a";
reg = <0x48>;
};
In this case, the sensor is mistakenly considered as ADT75 variant.
The simplest way to handle this issue is to make the LM75 code
zero.
Fixes: e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
Signed-off-by: Matwey V. Kornilov
---
drivers/hwmon/lm75.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index e447febd121a..3aa7f9454f57 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -25,12 +25,12 @@
*/
enum lm75_type { /* keep sorted in alphabetical order */
+ lm75 = 0, /* except of lm75 which is default fallback */
adt75,
ds1775,
ds75,
ds7505,
g751,
- lm75,
lm75a,
lm75b,
max6625,
--
2.26.2
[PATCH 1/2] hwmon: lm75: Add NXP LM75A to of_match list
NXP LM75A is compatible with original LM75A while it has improved
11-bit precision.
https://www.nxp.com/docs/en/data-sheet/LM75A.pdf
Signed-off-by: Matwey V. Kornilov
---
drivers/hwmon/lm75.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index 3aa7f9454f57..37dc903ebf54 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -699,6 +699,10 @@ static const struct of_device_id __maybe_unused
lm75_of_match[] = {
.compatible = "national,lm75b",
.data = (void *)lm75b
},
+ {
+ .compatible = "nxp,lm75a",
+ .data = (void *)lm75b
+ },
{
.compatible = "maxim,max6625",
.data = (void *)max6625
--
2.26.2
[PATCH 2/2] hwmon: lm75: Add another name for NXP LM75B to of_match list
NXP LM75B is compatible with original LM75A while it has improved
11-bit precision.
https://www.nxp.com/docs/en/data-sheet/LM75B.pdf
NXP LM75B support was added in
799fc6021430 ("hwmon: (lm75) Add support for the NXP LM75B")
OF compatible string "national,lm75b" for LM75B was created in
e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
Since the previous commit introduces "nxp,lm75a" compatible string
for LM75A, there is a reason to add another alias for LM75B.
Signed-off-by: Matwey V. Kornilov
---
drivers/hwmon/lm75.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index 37dc903ebf54..6cd951e062f0 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -703,6 +703,10 @@ static const struct of_device_id __maybe_unused
lm75_of_match[] = {
.compatible = "nxp,lm75a",
.data = (void *)lm75b
},
+ {
+ .compatible = "nxp,lm75b",
+ .data = (void *)lm75b
+ },
{
.compatible = "maxim,max6625",
.data = (void *)max6625
--
2.26.2
[PATCH v2] hwmon: lm75: Handle broken device nodes gracefully
There is a logical flaw in lm75_probe() function introduced in
commit e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
Note, that of_device_get_match_data() returns NULL when no match
found. This is the case when OF node exists but has unknown
compatible line, while the module is still loaded via i2c
detection.
arch/powerpc/boot/dts/fsl/p2041rdb.dts:
lm75b@48 {
compatible = "nxp,lm75a";
reg = <0x48>;
};
In this case, the sensor is mistakenly considered as ADT75 variant.
Fixes: e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
Signed-off-by: Matwey V. Kornilov
---
drivers/hwmon/lm75.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index e447febd121a..130ad5042107 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -561,9 +561,15 @@ static int lm75_probe(struct i2c_client *client)
int status, err;
enum lm75_type kind;
- if (client->dev.of_node)
- kind = (enum lm75_type)of_device_get_match_data(&client->dev);
- else
+ if (dev->of_node) {
+ const struct of_device_id *match =
+ of_match_device(dev->driver->of_match_table, dev);
+
+ if (!match)
+ return -ENODEV;
+
+ kind = (enum lm75_type)(match->data);
+ } else
kind = i2c_match_id(lm75_ids, client)->driver_data;
if (!i2c_check_functionality(client->adapter,
--
2.26.2
[PATCH v4 0/4] hwmon: lm75: Handle broken device nodes gracefully
This series is to fix a logical issue in lm75 driver. The actual fix is in the last patch. Other patches are present in order not to break existing users. Matwey V. Kornilov (4): hwmon: lm75: Add lm75 to of_match list hwmon: lm75: Add nxp,lm75a to of_match list hwmon: lm75: Add ti,lm75 to of_match list hwmon: lm75: Handle broken device nodes gracefully .../devicetree/bindings/hwmon/lm75.yaml | 3 ++ drivers/hwmon/lm75.c | 32 +-- 2 files changed, 32 insertions(+), 3 deletions(-) -- 2.26.2
[PATCH v4 3/4] hwmon: lm75: Add ti,lm75 to of_match list
Currently, armada-388-helios4.dts and nuvoton-npcm730-kudo.dts use
"ti,lm75" compatible string.
TI LM75A/B are compatible with original LM75A
https://www.ti.com/lit/ds/symlink/lm75a.pdf
https://www.ti.com/lit/ds/symlink/lm75b.pdf
Signed-off-by: Matwey V. Kornilov
---
Documentation/devicetree/bindings/hwmon/lm75.yaml | 1 +
drivers/hwmon/lm75.c | 4
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml
b/Documentation/devicetree/bindings/hwmon/lm75.yaml
index 8c3848f4c277..721e77ce4390 100644
--- a/Documentation/devicetree/bindings/hwmon/lm75.yaml
+++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml
@@ -32,6 +32,7 @@ properties:
- st,stds75
- st,stlm75
- microchip,tcn75
+ - ti,lm75
- ti,tmp100
- ti,tmp101
- ti,tmp105
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index 9c54c7d86771..3e4374aa2f99 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -750,6 +750,10 @@ static const struct of_device_id __maybe_unused
lm75_of_match[] = {
.compatible = "microchip,tcn75",
.data = (void *)tcn75
},
+ {
+ .compatible = "ti,lm75",
+ .data = (void *)lm75a
+ },
{
.compatible = "ti,tmp100",
.data = (void *)tmp100
--
2.26.2
[PATCH v4 2/4] hwmon: lm75: Add nxp,lm75a to of_match list
NXP LM75A is compatible with original LM75A while it has improved
11-bit precision.
https://www.nxp.com/docs/en/data-sheet/LM75A.pdf
Signed-off-by: Matwey V. Kornilov
---
Documentation/devicetree/bindings/hwmon/lm75.yaml | 1 +
drivers/hwmon/lm75.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml
b/Documentation/devicetree/bindings/hwmon/lm75.yaml
index aec8edd1e0c6..8c3848f4c277 100644
--- a/Documentation/devicetree/bindings/hwmon/lm75.yaml
+++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml
@@ -22,6 +22,7 @@ properties:
- national,lm75
- national,lm75a
- national,lm75b
+ - nxp,lm75a
- maxim,max6625
- maxim,max6626
- maxim,max31725
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index 08cde1c446db..9c54c7d86771 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -33,6 +33,7 @@ enum lm75_type { /* keep sorted in alphabetical
order */
lm75,
lm75a,
lm75b,
+ nxp_lm75,
max6625,
max6626,
max31725,
@@ -182,6 +183,11 @@ static const struct lm75_params device_params[] = {
.default_resolution = 11,
.default_sample_time = MSEC_PER_SEC / 10,
},
+ [nxp_lm75] = {
+ .default_resolution = 11,
+ .default_sample_time = MSEC_PER_SEC / 10,
+ .resolution_limits = 9,
+ },
[max6625] = {
.default_resolution = 9,
.default_sample_time = MSEC_PER_SEC / 7,
@@ -644,6 +650,7 @@ static const struct i2c_device_id lm75_ids[] = {
{ "lm75", lm75, },
{ "lm75a", lm75a, },
{ "lm75b", lm75b, },
+ { "nxp_lm75a", nxp_lm75, },
{ "max6625", max6625, },
{ "max6626", max6626, },
{ "max31725", max31725, },
@@ -703,6 +710,10 @@ static const struct of_device_id __maybe_unused
lm75_of_match[] = {
.compatible = "national,lm75b",
.data = (void *)lm75b
},
+ {
+ .compatible = "nxp,lm75a",
+ .data = (void *)nxp_lm75
+ },
{
.compatible = "maxim,max6625",
.data = (void *)max6625
--
2.26.2
[PATCH v4 1/4] hwmon: lm75: Add lm75 to of_match list
Currently, many boards use just 'lm75' as a compatible string.
Signed-off-by: Matwey V. Kornilov
---
Documentation/devicetree/bindings/hwmon/lm75.yaml | 1 +
drivers/hwmon/lm75.c | 4
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml
b/Documentation/devicetree/bindings/hwmon/lm75.yaml
index 96eed5cc7841..aec8edd1e0c6 100644
--- a/Documentation/devicetree/bindings/hwmon/lm75.yaml
+++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml
@@ -13,6 +13,7 @@ maintainers:
properties:
compatible:
enum:
+ - lm75
- adi,adt75
- dallas,ds1775
- dallas,ds75
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index e447febd121a..08cde1c446db 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -667,6 +667,10 @@ static const struct i2c_device_id lm75_ids[] = {
MODULE_DEVICE_TABLE(i2c, lm75_ids);
static const struct of_device_id __maybe_unused lm75_of_match[] = {
+ {
+ .compatible = "lm75",
+ .data = (void *)lm75
+ },
{
.compatible = "adi,adt75",
.data = (void *)adt75
--
2.26.2
[PATCH v4 4/4] hwmon: lm75: Handle broken device nodes gracefully
There is a logical flaw in lm75_probe() function introduced in
e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
Note, that of_device_get_match_data() returns NULL when no match
is found. This is the case when OF node exists but has unknown
compatible line, while the module is still loaded via i2c
detection.
arch/powerpc/boot/dts/fsl/p2041rdb.dts:
lm75b@48 {
compatible = "nxp,lm75a";
reg = <0x48>;
};
In this case, the sensor is mistakenly considered as ADT75 variant.
Fixes: e97a45f1b460 ("hwmon: (lm75) Add OF device ID table")
Signed-off-by: Matwey V. Kornilov
---
drivers/hwmon/lm75.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index 3e4374aa2f99..cd2cda4f557a 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -567,10 +567,17 @@ static int lm75_probe(struct i2c_client *client)
int status, err;
enum lm75_type kind;
- if (client->dev.of_node)
- kind = (enum lm75_type)of_device_get_match_data(&client->dev);
- else
+ if (dev->of_node) {
+ const struct of_device_id *match =
+ of_match_device(dev->driver->of_match_table, dev);
+
+ if (!match)
+ return -ENODEV;
+
+ kind = (enum lm75_type)(match->data);
+ } else {
kind = i2c_match_id(lm75_ids, client)->driver_data;
+ }
if (!i2c_check_functionality(client->adapter,
I2C_FUNC_SMBUS_BYTE_DATA | I2C_FUNC_SMBUS_WORD_DATA))
--
2.26.2
[PATCH] media: pwc: Use correct device for DMA
This fixes the following newly introduced warning:
[ 15.518253] [ cut here ]
[ 15.518941] WARNING: CPU: 0 PID: 246 at
/home/matwey/lab/linux/kernel/dma/mapping.c:149 dma_map_page_attrs+0x1a8/0x1d0
[ 15.520634] Modules linked in: pwc videobuf2_vmalloc videobuf2_memops
videobuf2_v4l2 videobuf2_common videodev mc efivarfs
[ 15.522335] CPU: 0 PID: 246 Comm: v4l2-test Not tainted 5.11.0-rc1+ #1
[ 15.523281] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0
02/06/2015
[ 15.524438] RIP: 0010:dma_map_page_attrs+0x1a8/0x1d0
[ 15.525135] Code: 10 5b 5d 41 5c 41 5d c3 4d 89 d0 eb d7 4d 89 c8 89 e9 48
89 da e8 68 29 00 00 eb d1 48 89 f2 48 2b 50 18 48 89 d0 eb 83 0f 0b <0f> 0b 48
c7 c0 ff ff ff ff eb b8 48 89 d9 48 8b 40 40 e8 61 69 d2
[ 15.527938] RSP: 0018:a2694047bca8 EFLAGS: 00010246
[ 15.528716] RAX: RBX: 2580 RCX:
[ 15.529782] RDX: RSI: cdce000ecc00 RDI: a0b4bdb888a0
[ 15.530849] RBP: 0002 R08: 0002 R09:
[ 15.531881] R10: 0004 R11: 0002d8c0 R12:
[ 15.532911] R13: a0b4bdb88800 R14: a0b48382 R15: a0b4bdb888a0
[ 15.533942] FS: 7fc5fbb5e4c0() GS:a0b4fc00()
knlGS:
[ 15.535141] CS: 0010 DS: ES: CR0: 80050033
[ 15.535988] CR2: 7fc5fb6ea138 CR3: 03812000 CR4: 001506f0
[ 15.537025] Call Trace:
[ 15.537425] start_streaming+0x2e9/0x4b0 [pwc]
[ 15.538143] vb2_start_streaming+0x5e/0x110 [videobuf2_common]
[ 15.538989] vb2_core_streamon+0x107/0x140 [videobuf2_common]
[ 15.539831] __video_do_ioctl+0x18f/0x4a0 [videodev]
[ 15.540670] video_usercopy+0x13a/0x5b0 [videodev]
[ 15.541349] ? video_put_user+0x230/0x230 [videodev]
[ 15.542096] ? selinux_file_ioctl+0x143/0x200
[ 15.542752] v4l2_ioctl+0x40/0x50 [videodev]
[ 15.543360] __x64_sys_ioctl+0x89/0xc0
[ 15.543930] do_syscall_64+0x33/0x40
[ 15.58] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 15.545236] RIP: 0033:0x7fc5fb671587
[ 15.545780] Code: b3 66 90 48 8b 05 11 49 2c 00 64 c7 00 26 00 00 00 48 c7
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d e1 48 2c 00 f7 d8 64 89 01 48
[ 15.548486] RSP: 002b:7fff0f71f038 EFLAGS: 0246 ORIG_RAX:
0010
[ 15.549578] RAX: ffda RBX: 0003 RCX: 7fc5fb671587
[ 15.550664] RDX: 7fff0f71f060 RSI: 40045612 RDI: 0003
[ 15.551706] RBP: R08: R09:
[ 15.552738] R10: R11: 0246 R12: 7fff0f71f060
[ 15.553817] R13: 7fff0f71f1d0 R14: 00de1270 R15:
[ 15.554914] ---[ end trace 7be03122966c2486 ]---
Fixes: 1161db6776bd ("media: usb: pwc: Don't use coherent DMA buffers for ISO
transfer")
Signed-off-by: Matwey V. Kornilov
---
drivers/media/usb/pwc/pwc-if.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
index 61869636ec61..5e3339cc31c0 100644
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -155,16 +155,17 @@ static const struct video_device pwc_template = {
/***/
/* Private functions */
-static void *pwc_alloc_urb_buffer(struct device *dev,
+static void *pwc_alloc_urb_buffer(struct usb_device *dev,
size_t size, dma_addr_t *dma_handle)
{
+ struct device *dmadev = dev->bus->sysdev;
void *buffer = kmalloc(size, GFP_KERNEL);
if (!buffer)
return NULL;
- *dma_handle = dma_map_single(dev, buffer, size, DMA_FROM_DEVICE);
- if (dma_mapping_error(dev, *dma_handle)) {
+ *dma_handle = dma_map_single(dmadev, buffer, size, DMA_FROM_DEVICE);
+ if (dma_mapping_error(dmadev, *dma_handle)) {
kfree(buffer);
return NULL;
}
@@ -172,12 +173,14 @@ static void *pwc_alloc_urb_buffer(struct device *dev,
return buffer;
}
-static void pwc_free_urb_buffer(struct device *dev,
+static void pwc_free_urb_buffer(struct usb_device *dev,
size_t size,
void *buffer,
dma_addr_t dma_handle)
{
- dma_unmap_single(dev, dma_handle, size, DMA_FROM_DEVICE);
+ struct device *dmadev = dev->bus->sysdev;
+
+ dma_unmap_single(dmadev, dma_handle, size, DMA_FROM_DEVICE);
kfree(buffer);
}
@@ -282,6 +285,7 @@ static void pwc_frame_complete(struct pwc_device *pdev)
static void pwc_isoc_handler(struct urb *urb)
{
struct pwc_device *pdev = (struct pwc_device *)urb->context
[PATCH RFC] drivers: parport: Ask user for irqreturn_t value
Current parport_irq_handler behaviour is not correct when IRQ is shared.
LDDv3 on page 279 requires us:
"Be sure to return IRQ_NONE whenever your handler is called and finds
the device is not interrupting."
This is not the case of parport_irq_handler.
Current implementation of IRQ handling use this to optimize shared IRQ
processing.
When an action returns IRQ_HANDLED no other actions are processed.
Modify callback function void (*irq_func)(void *) to irqreturn_t
(*irq_func)(void *) and return the value in parport_irq_handler
This also fixes https://bugzilla.kernel.org/show_bug.cgi?id=85221
Signed-off-by: Matwey V. Kornilov
---
drivers/char/ppdev.c | 4 +++-
drivers/i2c/busses/i2c-parport.c | 5 -
drivers/input/joystick/walkera0701.c | 6 --
drivers/net/hamradio/baycom_par.c | 4 +++-
drivers/net/plip/plip.c| 8 +---
drivers/parport/share.c| 6 ++
drivers/pps/clients/pps_parport.c | 6 +++---
drivers/staging/media/lirc/lirc_parallel.c | 12 +++-
include/linux/parport.h| 12
9 files changed, 39 insertions(+), 24 deletions(-)
diff --git a/drivers/char/ppdev.c b/drivers/char/ppdev.c
index ae0b42b..61fec51 100644
--- a/drivers/char/ppdev.c
+++ b/drivers/char/ppdev.c
@@ -264,7 +264,7 @@ static ssize_t pp_write (struct file * file, const char
__user * buf,
return bytes_written;
}
-static void pp_irq (void *private)
+static irqreturn_t pp_irq (void *private)
{
struct pp_struct *pp = private;
@@ -275,6 +275,8 @@ static void pp_irq (void *private)
atomic_inc (&pp->irqc);
wake_up_interruptible (&pp->irq_wait);
+
+ return IRQ_HANDLED;
}
static int register_device (int minor, struct pp_struct *pp)
diff --git a/drivers/i2c/busses/i2c-parport.c b/drivers/i2c/busses/i2c-parport.c
index a27aae2..7549e10 100644
--- a/drivers/i2c/busses/i2c-parport.c
+++ b/drivers/i2c/busses/i2c-parport.c
@@ -151,7 +151,7 @@ static const struct i2c_algo_bit_data parport_algo_data = {
/* - I2c and parallel port call-back functions and structures - */
-static void i2c_parport_irq(void *data)
+static irqreturn_t i2c_parport_irq(void *data)
{
struct i2c_par *adapter = data;
struct i2c_client *ara = adapter->ara;
@@ -159,9 +159,12 @@ static void i2c_parport_irq(void *data)
if (ara) {
dev_dbg(&ara->dev, "SMBus alert received\n");
i2c_handle_smbus_alert(ara);
+ return IRQ_HANDLED;
} else
dev_dbg(&adapter->adapter.dev,
"SMBus alert received but no ARA client!\n");
+
+ return IRQ_NONE;
}
static void i2c_parport_attach(struct parport *port)
diff --git a/drivers/input/joystick/walkera0701.c
b/drivers/input/joystick/walkera0701.c
index b76ac58..f3903a6 100644
--- a/drivers/input/joystick/walkera0701.c
+++ b/drivers/input/joystick/walkera0701.c
@@ -124,7 +124,7 @@ static inline int read_ack(struct pardevice *p)
}
/* falling edge, prepare to BIN value calculation */
-static void walkera0701_irq_handler(void *handler_data)
+static irqreturn_t walkera0701_irq_handler(void *handler_data)
{
u64 pulse_time;
struct walkera_dev *w = handler_data;
@@ -136,7 +136,7 @@ static void walkera0701_irq_handler(void *handler_data)
/* cancel timer, if in handler or active do resync */
if (unlikely(0 != hrtimer_try_to_cancel(&w->timer))) {
w->counter = NO_SYNC;
- return;
+ return IRQ_HANDLED;
}
if (w->counter < NO_SYNC) {
@@ -166,6 +166,8 @@ static void walkera0701_irq_handler(void *handler_data)
w->counter = 0;
hrtimer_start(&w->timer, ktime_set(0, BIN_SAMPLE), HRTIMER_MODE_REL);
+
+ return IRQ_HANDLED;
}
static enum hrtimer_restart timer_handler(struct hrtimer
diff --git a/drivers/net/hamradio/baycom_par.c
b/drivers/net/hamradio/baycom_par.c
index acb6369..1fd9a7b 100644
--- a/drivers/net/hamradio/baycom_par.c
+++ b/drivers/net/hamradio/baycom_par.c
@@ -269,7 +269,7 @@ static __inline__ void par96_rx(struct net_device *dev,
struct baycom_state *bc)
/* - */
-static void par96_interrupt(void *dev_id)
+static irqreturn_t par96_interrupt(void *dev_id)
{
struct net_device *dev = dev_id;
struct baycom_state *bc = netdev_priv(dev);
@@ -292,6 +292,8 @@ static void par96_interrupt(void *dev_id)
hdlcdrv_transmitter(dev, &bc->hdrv);
hdlcdrv_receiver(dev, &bc->hdrv);
local_irq_disable();
+
+ return IRQ_HANDLED;
}
/* - */
diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
index
Re: [PATCH RFC] drivers: parport: Ask user for irqreturn_t value
Forget it, I invented something strange.
2014-09-28 12:02 GMT+04:00 Matwey V. Kornilov :
> Current parport_irq_handler behaviour is not correct when IRQ is shared.
> LDDv3 on page 279 requires us:
>
> "Be sure to return IRQ_NONE whenever your handler is called and finds
> the device is not interrupting."
>
> This is not the case of parport_irq_handler.
> Current implementation of IRQ handling use this to optimize shared IRQ
> processing.
> When an action returns IRQ_HANDLED no other actions are processed.
>
> Modify callback function void (*irq_func)(void *) to irqreturn_t
> (*irq_func)(void *) and return the value in parport_irq_handler
>
> This also fixes https://bugzilla.kernel.org/show_bug.cgi?id=85221
>
> Signed-off-by: Matwey V. Kornilov
> ---
> drivers/char/ppdev.c | 4 +++-
> drivers/i2c/busses/i2c-parport.c | 5 -
> drivers/input/joystick/walkera0701.c | 6 --
> drivers/net/hamradio/baycom_par.c | 4 +++-
> drivers/net/plip/plip.c| 8 +---
> drivers/parport/share.c| 6 ++
> drivers/pps/clients/pps_parport.c | 6 +++---
> drivers/staging/media/lirc/lirc_parallel.c | 12 +++-
> include/linux/parport.h| 12
> 9 files changed, 39 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/char/ppdev.c b/drivers/char/ppdev.c
> index ae0b42b..61fec51 100644
> --- a/drivers/char/ppdev.c
> +++ b/drivers/char/ppdev.c
> @@ -264,7 +264,7 @@ static ssize_t pp_write (struct file * file, const char
> __user * buf,
> return bytes_written;
> }
>
> -static void pp_irq (void *private)
> +static irqreturn_t pp_irq (void *private)
> {
> struct pp_struct *pp = private;
>
> @@ -275,6 +275,8 @@ static void pp_irq (void *private)
>
> atomic_inc (&pp->irqc);
> wake_up_interruptible (&pp->irq_wait);
> +
> + return IRQ_HANDLED;
> }
>
> static int register_device (int minor, struct pp_struct *pp)
> diff --git a/drivers/i2c/busses/i2c-parport.c
> b/drivers/i2c/busses/i2c-parport.c
> index a27aae2..7549e10 100644
> --- a/drivers/i2c/busses/i2c-parport.c
> +++ b/drivers/i2c/busses/i2c-parport.c
> @@ -151,7 +151,7 @@ static const struct i2c_algo_bit_data parport_algo_data =
> {
>
> /* - I2c and parallel port call-back functions and structures -
> */
>
> -static void i2c_parport_irq(void *data)
> +static irqreturn_t i2c_parport_irq(void *data)
> {
> struct i2c_par *adapter = data;
> struct i2c_client *ara = adapter->ara;
> @@ -159,9 +159,12 @@ static void i2c_parport_irq(void *data)
> if (ara) {
> dev_dbg(&ara->dev, "SMBus alert received\n");
> i2c_handle_smbus_alert(ara);
> + return IRQ_HANDLED;
> } else
> dev_dbg(&adapter->adapter.dev,
> "SMBus alert received but no ARA client!\n");
> +
> + return IRQ_NONE;
> }
>
> static void i2c_parport_attach(struct parport *port)
> diff --git a/drivers/input/joystick/walkera0701.c
> b/drivers/input/joystick/walkera0701.c
> index b76ac58..f3903a6 100644
> --- a/drivers/input/joystick/walkera0701.c
> +++ b/drivers/input/joystick/walkera0701.c
> @@ -124,7 +124,7 @@ static inline int read_ack(struct pardevice *p)
> }
>
> /* falling edge, prepare to BIN value calculation */
> -static void walkera0701_irq_handler(void *handler_data)
> +static irqreturn_t walkera0701_irq_handler(void *handler_data)
> {
> u64 pulse_time;
> struct walkera_dev *w = handler_data;
> @@ -136,7 +136,7 @@ static void walkera0701_irq_handler(void *handler_data)
> /* cancel timer, if in handler or active do resync */
> if (unlikely(0 != hrtimer_try_to_cancel(&w->timer))) {
> w->counter = NO_SYNC;
> - return;
> + return IRQ_HANDLED;
> }
>
> if (w->counter < NO_SYNC) {
> @@ -166,6 +166,8 @@ static void walkera0701_irq_handler(void *handler_data)
> w->counter = 0;
>
> hrtimer_start(&w->timer, ktime_set(0, BIN_SAMPLE), HRTIMER_MODE_REL);
> +
> + return IRQ_HANDLED;
> }
>
> static enum hrtimer_restart timer_handler(struct hrtimer
> diff --git a/drivers/net/hamradio/baycom_par.c
> b/drivers/net/hamradio/baycom_par.c
> index acb6369..1fd9a7b 100644
> --- a/drivers/net/hamradio/baycom_par.c
> +++ b/drivers/net/hamradio/baycom_par.c
> @@ -269,7 +269,7 @@ static __inline__ void par96_rx(struct net_device *dev,
> struct bayco
[PATCH 0/2] Fix dependency loop in tusb6010
From: "Matwey V. Kornilov" Subject: [PATCH 0/2] Fix dependency loop in tusb6010 With the following configure options, musb_hdrc and tusb6010 make dependency loop: CONFIG_USB_MUSB_HDRC=m CONFIG_USB_MUSB_TUSB6010=m CONFIG_USB_TUSB_OMAP_DMA=y tusb6010.ko provides function `tusb_get_revision` which is used by tusb6010_omap.o which is a part of musb_hdrc.ko In its turn, tusb6010.ko uses much of functions provided by musb_hdrc.ko The following patches are to solve the issue. Signed-off-by: Matwey V. Kornilov -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Add tusb_revision to struct musb to store the revision.
From 0bd8c14855eeb049f49685f36386750a999078a3 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Fri, 9 May 2014 15:52:00 +0400
Subject: [PATCH 1/2] Add tusb_revision to struct musb to store the revision.
Add field to store tusb6010 revision value. Read the revision at
the startup and store to the variable.
Signed-off-by: Matwey V. Kornilov
---
drivers/usb/musb/musb_core.h | 1 +
drivers/usb/musb/tusb6010.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7083e82..d7dea2f 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -337,6 +337,7 @@ struct musb {
dma_addr_t async;
dma_addr_t sync;
void __iomem*sync_va;
+ u8 tusb_revision;
#endif
/* passed down from chip/board specific irq handlers */
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 4e9fb1d..81fa8fd 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -1011,6 +1011,7 @@ static int tusb_musb_start(struct musb *musb)
goto err;
}
+ musb->tusb_revision = tusb_get_revision(musb);
ret = tusb_print_revision(musb);
if (ret < 2) {
printk(KERN_ERR "tusb: Unsupported TUSB6010 revision %i\n",
--
1.8.1.4
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Use musb->tusb_revision instead of tusb_get_revision call.
From e24375ea6aefe2ad1ee72b8facab91abd1be190a Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Fri, 9 May 2014 16:10:16 +0400
Subject: [PATCH 2/2] Use musb->tusb_revision instead of tusb_get_revision call.
The value of the revision is stored in musb->tusb_revision,
so don't re-read it every time.
Exporting tusb_get_revision is not needed anymore,
so the dependency loop between tusb6010 and tusb6010_omap is resolved.
Signed-off-by: Matwey V. Kornilov
---
drivers/usb/musb/tusb6010.c | 19 ---
drivers/usb/musb/tusb6010.h | 2 --
drivers/usb/musb/tusb6010_omap.c | 2 +-
3 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 81fa8fd..d49415c 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -42,7 +42,7 @@ static void tusb_musb_set_vbus(struct musb *musb, int is_on);
* Checks the revision. We need to use the DMA register as 3.0 does not
* have correct versions for TUSB_PRCM_REV or TUSB_INT_CTRL_REV.
*/
-u8 tusb_get_revision(struct musb *musb)
+static u8 tusb_get_revision(struct musb *musb)
{
void __iomem*tbase = musb->ctrl_base;
u32 die_id;
@@ -58,14 +58,13 @@ u8 tusb_get_revision(struct musb *musb)
return rev;
}
-EXPORT_SYMBOL_GPL(tusb_get_revision);
-static int tusb_print_revision(struct musb *musb)
+static void tusb_print_revision(struct musb *musb)
{
void __iomem*tbase = musb->ctrl_base;
u8 rev;
- rev = tusb_get_revision(musb);
+ rev = musb->tusb_revision;
pr_info("tusb: %s%i.%i %s%i.%i %s%i.%i %s%i.%i %s%i %s%i.%i\n",
"prcm",
@@ -84,8 +83,6 @@ static int tusb_print_revision(struct musb *musb)
TUSB_DIDR1_HI_CHIP_REV(musb_readl(tbase, TUSB_DIDR1_HI)),
"rev",
TUSB_REV_MAJOR(rev), TUSB_REV_MINOR(rev));
-
- return tusb_get_revision(musb);
}
#define WBUS_QUIRK_MASK(TUSB_PHY_OTG_CTRL_TESTM2 |
TUSB_PHY_OTG_CTRL_TESTM1 \
@@ -349,7 +346,7 @@ static void tusb_allow_idle(struct musb *musb, u32
wakeup_enables)
u32 reg;
if ((wakeup_enables & TUSB_PRCM_WBUS)
- && (tusb_get_revision(musb) == TUSB_REV_30))
+ && (musb->tusb_revision == TUSB_REV_30))
tusb_wbus_quirk(musb, 1);
tusb_set_clock_source(musb, 0);
@@ -797,7 +794,7 @@ static irqreturn_t tusb_musb_interrupt(int irq, void *__hci)
u32 reg;
u32 i;
- if (tusb_get_revision(musb) == TUSB_REV_30)
+ if (musb->tusb_revision == TUSB_REV_30)
tusb_wbus_quirk(musb, 0);
/* there are issues re-locking the PLL on wakeup ... */
@@ -1012,10 +1009,10 @@ static int tusb_musb_start(struct musb *musb)
}
musb->tusb_revision = tusb_get_revision(musb);
- ret = tusb_print_revision(musb);
- if (ret < 2) {
+ tusb_print_revision(musb);
+ if (musb->tusb_revision < 2) {
printk(KERN_ERR "tusb: Unsupported TUSB6010 revision %i\n",
- ret);
+ musb->tusb_revision);
goto err;
}
diff --git a/drivers/usb/musb/tusb6010.h b/drivers/usb/musb/tusb6010.h
index 35c933a..3d40c63 100644
--- a/drivers/usb/musb/tusb6010.h
+++ b/drivers/usb/musb/tusb6010.h
@@ -12,8 +12,6 @@
#ifndef __TUSB6010_H__
#define __TUSB6010_H__
-extern u8 tusb_get_revision(struct musb *musb);
-
#ifdef CONFIG_USB_TUSB6010
#define musb_in_tusb() 1
#else
diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index e33b6b2..3ce152c 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -677,7 +677,7 @@ struct dma_controller *dma_controller_create(struct musb
*musb, void __iomem *ba
tusb_dma->controller.channel_program = tusb_omap_dma_program;
tusb_dma->controller.channel_abort = tusb_omap_dma_abort;
- if (tusb_get_revision(musb) >= TUSB_REV_30)
+ if (musb->tusb_revision >= TUSB_REV_30)
tusb_dma->multichannel = 1;
for (i = 0; i < MAX_DMAREQ; i++) {
--
1.8.1.4
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 2/2] gpu: drm: omapdrm: Change struct pat data_pa type to dma_addr_t
From: "Matwey V. Kornilov"
The single one use-case for data_pa member of the struct pat is to carry a
value of dma_addr_t type.
This patch solves the following compilation error:
../drivers/gpu/drm/omapdrm/omap_dmm_tiler.c: In function 'dmm_txn_append':
../drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:226:2: error: passing argument 3 of
'alloc_dma' from incompatible pointer type [-Werror]
data = alloc_dma(txn, 4*i, &pat->data_pa);
^
../drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:77:14: note: expected 'dma_addr_t
*' but argument is of type 'uint32_t *'
static void *alloc_dma(struct dmm_txn *txn, size_t sz, dma_addr_t *pa)
^
Signed-off-by: Matwey V. Kornilov
---
drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
index 58bcd6a..4142525 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
@@ -105,7 +105,7 @@ struct pat {
uint32_t next_pa;
struct pat_area area;
struct pat_ctrl ctrl;
- uint32_t data_pa;
+ dma_addr_t data_pa;
};
#define DMM_FIXED_RETRY_COUNT 1000
--
1.8.1.4
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 1/2] gpu: drm: omapdrm: Use %pad format for values of the dma_addr_t type
From: "Matwey V. Kornilov"
The format change is to fix the following compilation issue:
../drivers/gpu/drm/omapdrm/omap_plane.c: In function 'omap_plane_pre_apply':
../drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects
argument of type 'unsigned int', but argument 5 has type 'dma_addr_t'
[-Werror=format=]
DBG("%d,%d %08x %08x", info->pos_x, info->pos_y,
^
../drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects
argument of type 'unsigned int', but argument 6 has type 'dma_addr_t'
[-Werror=format=]
cc1: all warnings being treated as errors
../scripts/Makefile.build:273: recipe for target
'drivers/gpu/drm/omapdrm/omap_plane.o' failed
Signed-off-by: Matwey V. Kornilov
---
drivers/gpu/drm/omapdrm/omap_gem.c | 10 +-
drivers/gpu/drm/omapdrm/omap_plane.c | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 95dbce2..d9f5e524 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -791,7 +791,7 @@ int omap_gem_get_paddr(struct drm_gem_object *obj,
omap_obj->paddr = tiler_ssptr(block);
omap_obj->block = block;
- DBG("got paddr: %08x", omap_obj->paddr);
+ DBG("got paddr: %pad", &omap_obj->paddr);
}
omap_obj->paddr_cnt++;
@@ -985,9 +985,9 @@ void omap_gem_describe(struct drm_gem_object *obj, struct
seq_file *m)
off = drm_vma_node_start(&obj->vma_node);
- seq_printf(m, "%08x: %2d (%2d) %08llx %08Zx (%2d) %p %4d",
+ seq_printf(m, "%08x: %2d (%2d) %08llx %pad (%2d) %p %4d",
omap_obj->flags, obj->name,
obj->refcount.refcount.counter,
- off, omap_obj->paddr, omap_obj->paddr_cnt,
+ off, &omap_obj->paddr, omap_obj->paddr_cnt,
omap_obj->vaddr, omap_obj->roll);
if (omap_obj->flags & OMAP_BO_TILED) {
@@ -1467,8 +1467,8 @@ void omap_gem_init(struct drm_device *dev)
entry->paddr = tiler_ssptr(block);
entry->block = block;
- DBG("%d:%d: %dx%d: paddr=%08x stride=%d", i, j, w, h,
- entry->paddr,
+ DBG("%d:%d: %dx%d: paddr=%pad stride=%d", i, j, w, h,
+ &entry->paddr,
usergart[i].stride_pfn << PAGE_SHIFT);
}
}
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 3cf31ee..6af3398 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -142,8 +142,8 @@ static void omap_plane_pre_apply(struct omap_drm_apply
*apply)
DBG("%dx%d -> %dx%d (%d)", info->width, info->height,
info->out_width, info->out_height,
info->screen_width);
- DBG("%d,%d %08x %08x", info->pos_x, info->pos_y,
- info->paddr, info->p_uv_addr);
+ DBG("%d,%d %pad %pad", info->pos_x, info->pos_y,
+ &info->paddr, &info->p_uv_addr);
/* TODO: */
ilace = false;
--
1.8.1.4
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-parport] [PATCHv3 2/2] Add force_epp module option for parport_pc.
Here usb-stick image with the new (Alan) version of the patches. https://susestudio.com/download/1cbfcf5c4ca89206fc170f00b962be0a/openSUSE_13.1_parport_pc.i686-0.1.0.oem.tar.gz login root:linux or tux:linux Heiko, could you please also check that you see EPP? 2014-07-11 1:48 GMT+04:00 Leopold Palomo-Avellaneda : > Hi, > > this thread has been very interesting. I feel that I'm one of the > "instigators" to solve this f... bug in the kernel. But, it seems that it's > quiet difficult, more because the kernel developers than the bug itself. > > But well, to be honest, the kernel developers do a great and complex job, so > probably they have good reasons to react in that way. Think that it's the > second time that a patch to solve this bug is rejected. > > Thanks Matwey for the patch and the afford to solve this bug. I have several > boxes in the lab where I work (Dell 745) that suffer that false positives. > > Also, there's some pci card that also suffer that. I think that we have one. > But, I'm not sure. > > So, I can check whatever could be necessary. > > Best regards, > > Leopold > > > > > -- > -- > Linux User 152692 PGP: 05F4A7A949A2D9AA > Catalonia > - > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-parport] [PATCH 2/2] parport: parport_pc: Add force_epp module option for parport_pc.
+#ifdef CONFIG_PARPORT_1284 +MODULE_PARM_DESC(force_epp, "Do not disable EPP when it is detected to be broken (default is false)"); I think this needs some more explanation - how about "Disable check for broken Intel EPP hardware that gives false positives on 2002 and newer hardware" I would like to keep force_epp option reusable, then description should be hardware-agnostic. Maybe: "Force EPP enabling when buggy hardware found by the module checks." -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] parport: parport_pc: Introduce intel_bug_present function.
From 28bb276ff858caecddfde78133f6b5b261c40a59 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Wed, 25 Jun 2014 00:53:54 +0400
Subject: [PATCH 1/2] parport: parport_pc: Introduce intel_bug_present function.
Put the code to check present of the Intel bug from parport_EPP_supported
into new intel_bug_present function. The later also return ECR register
to the state it has before function call.
Tested-by: Heiko Andreas Sommer
Signed-off-by: Matwey V. Kornilov
---
drivers/parport/parport_pc.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 76ee775..4b851bb 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -1702,6 +1702,29 @@ static int parport_ECP_supported(struct parport *pb)
}
#endif
+static int intel_bug_present(struct parport *pb)
+{
+ int bug_present = 0;
+
+ if (priv->ecr) {
+ /* store value of ECR */
+ unsigned char ecr = inb(ECONTROL(pb));
+ unsigned char i;
+ for (i = 0x00; i < 0x80; i += 0x20) {
+ ECR_WRITE(pb, i);
+ if (clear_epp_timeout(pb)) {
+ /* Phony EPP in ECP. */
+ bug_present = 1;
+ break;
+ }
+ }
+ /* return ECR into the inital state */
+ ECR_WRITE(pb, ecr);
+ }
+
+ return bug_present;
+}
+
static int parport_ECPPS2_supported(struct parport *pb)
{
const struct parport_pc_private *priv = pb->private_data;
@@ -1742,16 +1765,8 @@ static int parport_EPP_supported(struct parport *pb)
return 0; /* No way to clear timeout */
/* Check for Intel bug. */
- if (priv->ecr) {
- unsigned char i;
- for (i = 0x00; i < 0x80; i += 0x20) {
- ECR_WRITE(pb, i);
- if (clear_epp_timeout(pb)) {
- /* Phony EPP in ECP. */
- return 0;
- }
- }
- }
+ if (intel_bug_present(pb))
+ return 0;
pb->modes |= PARPORT_MODE_EPP;
--
1.8.1.4
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] parport: parport_pc: Introduce option to disable checking for Intel bug
From: "Matwey V. Kornilov" Date: Wed, 25 Jun 2014 00:53:54 +0400 Subject: [PATCH 0/2] parport: parport_pc: Introduce option to disable checking for Intel bug Hi, The following patch series is to deal with the issue on false-positives of Intel EPP bug check [1]. More than a decade ago, the check was introduced in order to prevent EPP operation on the some Intel LPT chipsets. The main issue to defence from was CPU hang at EPP operation on broken chipsets. It is mentioned that affected chipsets are Intel 82091. However, it is not known whether there are others. The check was implemented in a strange manner. Now, there is no explanations why. The check itself now leads to the false-positives, disabling EPP on many PC-s (Dell OptiPlex series for instance). The latter is an issue. Given that our knowledge of the initial problem is quite limited now, I introduce special option for parport_pc, allowing user to disable check. This won't introduce regressions. The patches organized as following: 1. Introduce-intel_bug_present-function. The transparent refactoring of the check is performed. Make the check be immutable regarding to ECR register. 2. Add force_epp module option for parport_pc. Additional option `force_epp` for parport_pc is introduced. The behaviour is the following: modprobe parport_pc # check is enabled, given there is no defaults # in /etc/modprobe.d/* modprobe parport_pc force_epp=0 # check is enabled modprobe parport_pc force_epp=1 # check is disabled [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630593 Tested-by: Heiko Andreas Sommer Signed-off-by: Matwey V. Kornilov -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] parport: parport_pc: Add force_epp module option for parport_pc.
From f5384f47688c116ac765b18bfb01e28b4233b97f Mon Sep 17 00:00:00 2001 From: "Matwey V. Kornilov" Date: Wed, 25 Jun 2014 01:08:45 +0400 Subject: [PATCH 2/2] parport: parport_pc: Add force_epp module option for parport_pc. The detection of Intel EPP bug is known to produce much false positives. The new option is introduced to force enable EPP in spite of the test result. Tested-by: Heiko Andreas Sommer Signed-off-by: Matwey V. Kornilov --- drivers/parport/parport_pc.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c index 4b851bb..1a15b9c 100644 --- a/drivers/parport/parport_pc.c +++ b/drivers/parport/parport_pc.c @@ -105,6 +105,9 @@ static int user_specified; (defined(CONFIG_PARPORT_1284) && defined(CONFIG_PARPORT_PC_FIFO)) static int verbose_probing; #endif +#ifdef CONFIG_PARPORT_1284 +static int force_epp; +#endif static int pci_registered_parport; static int pnp_registered_parport; @@ -1765,7 +1768,7 @@ static int parport_EPP_supported(struct parport *pb) return 0; /* No way to clear timeout */ /* Check for Intel bug. */ - if (intel_bug_present(pb)) + if (!force_epp && intel_bug_present(pb)) return 0; pb->modes |= PARPORT_MODE_EPP; @@ -3148,6 +3151,10 @@ module_param_array(dma, charp, NULL, 0); MODULE_PARM_DESC(verbose_probing, "Log chit-chat during initialisation"); module_param(verbose_probing, int, 0644); #endif +#ifdef CONFIG_PARPORT_1284 +MODULE_PARM_DESC(force_epp, "Do not disable EPP when it is detected to be broken (default is false)"); +module_param(force_epp, int, 0); +#endif #ifdef CONFIG_PCI static char *init_mode; MODULE_PARM_DESC(init_mode, -- 1.8.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 1/2] parport: parport_pc: Introduce intel_bug_present function.
From c89138e2c968c07dd11b3c6bfc05a803d0c5434d Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Wed, 25 Jun 2014 00:53:54 +0400
Subject: [PATCHv2 1/2] parport: parport_pc: Introduce intel_bug_present
function.
Put the code to check present of the Intel bug from parport_EPP_supported
into new intel_bug_present function. The later also return ECR register
to the state it has before function call.
Tested-by: Heiko Andreas Sommer
Signed-off-by: Matwey V. Kornilov
---
drivers/parport/parport_pc.c | 38 ++
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 76ee775..a6eaafb 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -1702,6 +1702,30 @@ static int parport_ECP_supported(struct parport *pb)
}
#endif
+static int intel_bug_present(struct parport *pb)
+{
+ const struct parport_pc_private *priv = pb->private_data;
+ int bug_present = 0;
+
+ if (priv->ecr) {
+ /* store value of ECR */
+ unsigned char ecr = inb(ECONTROL(pb));
+ unsigned char i;
+ for (i = 0x00; i < 0x80; i += 0x20) {
+ ECR_WRITE(pb, i);
+ if (clear_epp_timeout(pb)) {
+ /* Phony EPP in ECP. */
+ bug_present = 1;
+ break;
+ }
+ }
+ /* return ECR into the inital state */
+ ECR_WRITE(pb, ecr);
+ }
+
+ return bug_present;
+}
+
static int parport_ECPPS2_supported(struct parport *pb)
{
const struct parport_pc_private *priv = pb->private_data;
@@ -1722,8 +1746,6 @@ static int parport_ECPPS2_supported(struct parport *pb)
static int parport_EPP_supported(struct parport *pb)
{
- const struct parport_pc_private *priv = pb->private_data;
-
/*
* Theory:
* Bit 0 of STR is the EPP timeout bit, this bit is 0
@@ -1742,16 +1764,8 @@ static int parport_EPP_supported(struct parport *pb)
return 0; /* No way to clear timeout */
/* Check for Intel bug. */
- if (priv->ecr) {
- unsigned char i;
- for (i = 0x00; i < 0x80; i += 0x20) {
- ECR_WRITE(pb, i);
- if (clear_epp_timeout(pb)) {
- /* Phony EPP in ECP. */
- return 0;
- }
- }
- }
+ if (intel_bug_present(pb))
+ return 0;
pb->modes |= PARPORT_MODE_EPP;
--
1.8.1.4
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/2] Add force_epp module option for parport_pc.
On Wed, 9 Jul 2014, Greg KH wrote: On Mon, Jul 07, 2014 at 11:01:51AM +0400, Matwey V. Kornilov wrote: From cf37d0cc4d51da5c0b368e1f5ab05082c041d1e1 Mon Sep 17 00:00:00 2001 From: "Matwey V. Kornilov" Date: Wed, 25 Jun 2014 01:08:45 +0400 Subject: [PATCHv3 2/2] Add force_epp module option for parport_pc. The detection of Intel EPP bug is known to produce much false positives. The new option is introduced to force enable EPP in spite of the test result. Hi, First of all, maybe I missed something fundamental, or did something wrong, but I can't understand how is it going to break working systems? We have current behaviour B0, and introduce an option switches between B0 (which is default value) and alternative behaviour B1. So, until you go to /etc/modprobe.d to override defaults or modprobe with specific option the current behaviour B0 is active. Am I not right here? module parameters are horrid, how is someone supposed to know to use this? I usually do `modinfo' to list existing options. Do I understand right that description has to be added into Documentations also? Why can't we "fix" the detection logic? Initial check had been introduced in 1999 [1], however I am failed to find any proves, because davej/history.git is missed. Initial committer is unknown. The check fixes issue with the affected hardware (A) and introduces new one with false-positive (F) hardware. Now, there are no evidences of what hardware is affected (it seems to be quite aged), and no owners of this hardware are known. So, If I had fixed the detection logic (in one or another way), I would have not been able to check it. What I am trying to do here (as it is described in 0/2) is to allow people with false-positive hardware somehow operate with it. You just now broke systems that were working by forcing them to now set a module option where previously they didn't See above. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630593#79 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/2] Add force_epp module option for parport_pc.
2014-07-10 18:11 GMT+04:00 Dave Jones : > On Thu, Jul 10, 2014 at 11:56:15AM +0400, Matwey V. Kornilov wrote: > > > Initial check had been introduced in 1999 [1], however I am failed to find > > any proves, because davej/history.git is missed. > > https://archive.org/details/git-history-of-linux Thank you, Dave. This was introduced by cecd99566ac6aba844ff296e461f88131013da94 (2.3.10). In lkml archives I've found that this code is probably belongs to David Campbell, whose email has been dropped as bounced. So, I don't have any idea whether we can contact him. -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/2] Add force_epp module option for parport_pc.
2014-07-10 21:09 GMT+04:00 Greg KH : > On Thu, Jul 10, 2014 at 11:56:15AM +0400, Matwey V. Kornilov wrote: >> >> >> On Wed, 9 Jul 2014, Greg KH wrote: >> >> >On Mon, Jul 07, 2014 at 11:01:51AM +0400, Matwey V. Kornilov wrote: >> >>>From cf37d0cc4d51da5c0b368e1f5ab05082c041d1e1 Mon Sep 17 00:00:00 2001 >> >>From: "Matwey V. Kornilov" >> >>Date: Wed, 25 Jun 2014 01:08:45 +0400 >> >>Subject: [PATCHv3 2/2] Add force_epp module option for parport_pc. >> >> >> >>The detection of Intel EPP bug is known to produce much false positives. >> >>The new option is introduced to force enable EPP in spite of the test >> >>result. >> >> Hi, >> >> First of all, maybe I missed something fundamental, or did something wrong, >> but I can't understand how is it going to break working systems? > > I thought you disabled the quirk test and now rely on the module option > instead. That would require a machine that was happily relying on the > quirk test to now be forced to add a module option, right? No, this would not... > Or did I read the patch incorrectly? Maybe I've implemented something incorrectly? I think I suggested exactly inverse thing: the check is disabled only when the option is touched by user: !force_epp && intel_bug_present(pb) <=> intel_bug_present(pb) (given that force_epp is false) > Why not implement Alan's suggestion? Why not, if you are fine with it. Are you sure that PPro was turning point? -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 2/2] Add force_epp module option for parport_pc.
Or did I read the patch incorrectly? Maybe I've implemented something incorrectly? I think I suggested exactly inverse thing: the check is disabled only when the option is touched by user: !force_epp && intel_bug_present(pb) <=> intel_bug_present(pb) (given that force_epp is false) I don't understand, care to just resend the patches? I really don't remember what the patch said... The patch is in bottom of this message. My suggestion was that people suffering from false positives will set the option to TRUE, and other won't touch it. Why not implement Alan's suggestion? Why not, if you are fine with it. Are you sure that PPro was turning point? If Alan says so, I believe him :) Ok, then I believe you, I will go to reimplement it in Alan's way. From cf37d0cc4d51da5c0b368e1f5ab05082c041d1e1 Mon Sep 17 00:00:00 2001 From: "Matwey V. Kornilov" Date: Wed, 25 Jun 2014 01:08:45 +0400 Subject: [PATCH 2/2] Add force_epp module option for parport_pc. The detection of Intel EPP bug is known to produce much false positives. The new option is introduced to force enable EPP in spite of the test result. Tested-by: Heiko Andreas Sommer Signed-off-by: Matwey V. Kornilov --- drivers/parport/parport_pc.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c index a6eaafb..fb7530d 100644 --- a/drivers/parport/parport_pc.c +++ b/drivers/parport/parport_pc.c @@ -105,6 +105,9 @@ static int user_specified; (defined(CONFIG_PARPORT_1284) && defined(CONFIG_PARPORT_PC_FIFO)) static int verbose_probing; #endif +#ifdef CONFIG_PARPORT_1284 +static int force_epp; +#endif static int pci_registered_parport; static int pnp_registered_parport; @@ -1764,7 +1767,7 @@ static int parport_EPP_supported(struct parport *pb) return 0; /* No way to clear timeout */ /* Check for Intel bug. */ - if (intel_bug_present(pb)) + if (!force_epp && intel_bug_present(pb)) return 0; pb->modes |= PARPORT_MODE_EPP; @@ -3147,6 +3150,10 @@ module_param_array(dma, charp, NULL, 0); MODULE_PARM_DESC(verbose_probing, "Log chit-chat during initialisation"); module_param(verbose_probing, int, 0644); #endif +#ifdef CONFIG_PARPORT_1284 +MODULE_PARM_DESC(force_epp, "Force EPP enabling when buggy hardware found by the module checks"); +module_param(force_epp, int, 0); +#endif #ifdef CONFIG_PCI static char *init_mode; MODULE_PARM_DESC(init_mode, -- 1.8.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 0/2] parport: parport_pc: Introduce option to disable checking for Intel bug
From: "Matwey V. Kornilov" Date: Wed, 25 Jun 2014 00:53:54 +0400 Subject: [PATCHv3 0/2] parport: parport_pc: Introduce option to disable checking for Intel bug Hi, The following patch series is to deal with the issue on false-positives of Intel EPP bug check [1]. More than a decade ago, the check was introduced in order to prevent EPP operation on the some Intel LPT chipsets. The main issue to defence from was CPU hang at EPP operation on broken chipsets. It is mentioned that affected chipsets are Intel 82091. However, it is not known whether there are others. The check was implemented in strange manner. Now, there is no explanations why. The check itself now leads to the false-positives, disabling EPP on many PC-s (Dell OptiPlex series for instance). The latter is an issue. Given that our knowledge of the initial problem is quite limited now, I introduce special option for parport_pc, allowing user to disable check. This won't introduce regressions. The patches organized as following: 1. Introduce-intel_bug_present-function. The transparent refactoring of the check is performed. Make the check be immutable regarding to ECR register. 2. Add force_epp module option for parport_pc. Additional option for parport_pc is introduced. The behaviour is the following: modprobe parport_pc # check is enabled, given there is no defaults # in /etc/modprobe.d/* modprobe parport_pc force_epp=0 # check is enabled modprobe parport_pc force_epp=1 # check is disabled [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630593 Tested-by: Heiko Andreas Sommer Signed-off-by: Matwey V. Kornilov --- Changes from v2: - The module option has more clear description Changes from v1: - Patch 1 fetched from right branch and now compiled -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 1/2] Introduce intel_bug_present function.
From c89138e2c968c07dd11b3c6bfc05a803d0c5434d Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Wed, 25 Jun 2014 00:53:54 +0400
Subject: [PATCHv3 1/2] Introduce intel_bug_present function.
Put the code to check present of the Intel bug from parport_EPP_supported
into new intel_bug_present function. The later also return ECR register
to the state it has before function call.
Tested-by: Heiko Andreas Sommer
Signed-off-by: Matwey V. Kornilov
---
drivers/parport/parport_pc.c | 38 ++
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 76ee775..a6eaafb 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -1702,6 +1702,30 @@ static int parport_ECP_supported(struct parport *pb)
}
#endif
+static int intel_bug_present(struct parport *pb)
+{
+ const struct parport_pc_private *priv = pb->private_data;
+ int bug_present = 0;
+
+ if (priv->ecr) {
+ /* store value of ECR */
+ unsigned char ecr = inb(ECONTROL(pb));
+ unsigned char i;
+ for (i = 0x00; i < 0x80; i += 0x20) {
+ ECR_WRITE(pb, i);
+ if (clear_epp_timeout(pb)) {
+ /* Phony EPP in ECP. */
+ bug_present = 1;
+ break;
+ }
+ }
+ /* return ECR into the inital state */
+ ECR_WRITE(pb, ecr);
+ }
+
+ return bug_present;
+}
+
static int parport_ECPPS2_supported(struct parport *pb)
{
const struct parport_pc_private *priv = pb->private_data;
@@ -1722,8 +1746,6 @@ static int parport_ECPPS2_supported(struct parport *pb)
static int parport_EPP_supported(struct parport *pb)
{
- const struct parport_pc_private *priv = pb->private_data;
-
/*
* Theory:
* Bit 0 of STR is the EPP timeout bit, this bit is 0
@@ -1742,16 +1764,8 @@ static int parport_EPP_supported(struct parport *pb)
return 0; /* No way to clear timeout */
/* Check for Intel bug. */
- if (priv->ecr) {
- unsigned char i;
- for (i = 0x00; i < 0x80; i += 0x20) {
- ECR_WRITE(pb, i);
- if (clear_epp_timeout(pb)) {
- /* Phony EPP in ECP. */
- return 0;
- }
- }
- }
+ if (intel_bug_present(pb))
+ return 0;
pb->modes |= PARPORT_MODE_EPP;
--
1.8.1.4
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 2/2] Add force_epp module option for parport_pc.
From cf37d0cc4d51da5c0b368e1f5ab05082c041d1e1 Mon Sep 17 00:00:00 2001 From: "Matwey V. Kornilov" Date: Wed, 25 Jun 2014 01:08:45 +0400 Subject: [PATCHv3 2/2] Add force_epp module option for parport_pc. The detection of Intel EPP bug is known to produce much false positives. The new option is introduced to force enable EPP in spite of the test result. Tested-by: Heiko Andreas Sommer Signed-off-by: Matwey V. Kornilov --- drivers/parport/parport_pc.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c index a6eaafb..fb7530d 100644 --- a/drivers/parport/parport_pc.c +++ b/drivers/parport/parport_pc.c @@ -105,6 +105,9 @@ static int user_specified; (defined(CONFIG_PARPORT_1284) && defined(CONFIG_PARPORT_PC_FIFO)) static int verbose_probing; #endif +#ifdef CONFIG_PARPORT_1284 +static int force_epp; +#endif static int pci_registered_parport; static int pnp_registered_parport; @@ -1764,7 +1767,7 @@ static int parport_EPP_supported(struct parport *pb) return 0; /* No way to clear timeout */ /* Check for Intel bug. */ - if (intel_bug_present(pb)) + if (!force_epp && intel_bug_present(pb)) return 0; pb->modes |= PARPORT_MODE_EPP; @@ -3147,6 +3150,10 @@ module_param_array(dma, charp, NULL, 0); MODULE_PARM_DESC(verbose_probing, "Log chit-chat during initialisation"); module_param(verbose_probing, int, 0644); #endif +#ifdef CONFIG_PARPORT_1284 +MODULE_PARM_DESC(force_epp, "Force EPP enabling when buggy hardware found by the module checks"); +module_param(force_epp, int, 0); +#endif #ifdef CONFIG_PCI static char *init_mode; MODULE_PARM_DESC(init_mode, -- 1.8.1.4 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dts: Add UARTs to am335x-bone-common.dtsi
From 739cee0aded1aac80764b3fca4e801464f199f93 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Sat, 7 Jun 2014 17:23:57 +0400
Subject: [PATCH] Add UARTs to am335x-bone-common.dtsi
Add four UARTs pinouts and ports to beagle bone common dtsi.
Signed-off-by: Matwey V. Kornilov
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 48 +++
1 file changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2e7d932..da3db9f 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -90,6 +90,30 @@
0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
>;
};
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins = <
+ 0x180 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart1_rxd.uart1_rxd */
+ 0x184 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart1_txd.uart1_txd */
+ >;
+ };
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins = <
+ 0x150 (PIN_INPUT_PULLUP | MUX_MODE1)/*
spi0_sclk.uart2_rxd */
+ 0x154 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
spi0_d0.uart2_txd */
+ >;
+ };
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins = <
+ /* Pin 0x160 spi0_cs1.uart3_rxd is not exported to the expansion
header. The port is half-duplex */
+ 0x164 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
ecap0_in_pwm0_out.uart3_txd */
+ >;
+ };
+ uart4_pins: pinmux_uart4_pins {
+ pinctrl-single,pins = <
+ 0x070 (PIN_INPUT_PULLUP | MUX_MODE6)/*
gpmc_wait0.uart4_rxd */
+ 0x074 (PIN_OUTPUT_PULLDOWN | MUX_MODE6) /*
gpmc_wpn.uart4_txd */
+ >;
+ };
clkout2_pin: pinmux_clkout2_pin {
pinctrl-single,pins = <
@@ -179,6 +203,30 @@
status = "okay";
};
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+
+ status = "okay";
+};
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+
+ status = "okay";
+};
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>;
+
+ status = "okay";
+};
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart4_pins>;
+
+ status = "okay";
+};
&usb {
status = "okay";
--
1.8.1.4
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] dts: Add UARTs to am335x-bone-common.dtsi
From 570b6d0f050aa00d301e2ee9000c8fcb6db75df1 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Sat, 7 Jun 2014 17:23:57 +0400
Subject: [PATCH] Add UARTs to am335x-bone-common.dtsi
Add five UARTs pinouts and ports to Beagle Bone common dtsi.
Signed-off-by: Matwey V. Kornilov
---
Changes from v1 of the patch:
+ add uart5 initially lost
+ left uarts disabled
arch/arm/boot/dts/am335x-bone-common.dtsi | 50 +++
1 file changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2e7d932..dad68a1 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -90,6 +90,36 @@
0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
>;
};
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins = <
+ 0x180 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart1_rxd.uart1_rxd */
+ 0x184 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart1_txd.uart1_txd */
+ >;
+ };
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins = <
+ 0x150 (PIN_INPUT_PULLUP | MUX_MODE1)/*
spi0_sclk.uart2_rxd */
+ 0x154 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
spi0_d0.uart2_txd */
+ >;
+ };
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins = <
+ /* Pin 0x160 spi0_cs1.uart3_rxd is not exported to the expansion
header. The port is half-duplex */
+ 0x164 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /*
ecap0_in_pwm0_out.uart3_txd */
+ >;
+ };
+ uart4_pins: pinmux_uart4_pins {
+ pinctrl-single,pins = <
+ 0x070 (PIN_INPUT_PULLUP | MUX_MODE6)/*
gpmc_wait0.uart4_rxd */
+ 0x074 (PIN_OUTPUT_PULLDOWN | MUX_MODE6) /*
gpmc_wpn.uart4_txd */
+ >;
+ };
+ uart5_pins: pinmux_uart5_pins {
+ pinctrl-single,pins = <
+ 0x0c4 (PIN_INPUT_PULLUP | MUX_MODE4)/*
lcd_data9.uart5_rxd */
+ 0x0c0 (PIN_OUTPUT_PULLDOWN | MUX_MODE4) /*
lcd_data8.uart5_txd */
+ >;
+ };
clkout2_pin: pinmux_clkout2_pin {
pinctrl-single,pins = <
@@ -179,6 +209,26 @@
status = "okay";
};
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+};
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+};
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>;
+};
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart4_pins>;
+};
+&uart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart5_pins>;
+};
&usb {
status = "okay";
--
1.8.1.4
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dts: Add UARTs to am335x-bone-common.dtsi
On Sat, 7 Jun 2014, Robert Nelson wrote: These need to stay disabled in mainline, so drop the status = "okay"; , (till we get a working capemgr/overlay). Otherwise the pinmuxing looks good. What chances that we will eventually have working overlay in the mainline? -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpu: drm: msm: Replace type of paddr to uint32_t.
From e7147352639fd8f92b1cc85cff9bc5046c7a2130 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov"
Date: Mon, 2 Jun 2014 20:17:29 +0400
Subject: [PATCH] Replace type of paddr to uint32_t.
This patch helps to avoid the following build issue:
drivers/gpu/drm/msm/msm_fbdev.c:108:2: error: passing argument 3 of
'msm_gem_get_iova_locked' from incompatible pointer type [-Werror]
msm_gem_get_iova_locked(fbdev->bo, 0, &paddr);
^
In file included from drivers/gpu/drm/msm/msm_fbdev.c:18:0:
drivers/gpu/drm/msm/msm_drv.h:153:5: note: expected 'uint32_t *' but argument
is of type 'dma_addr_t *'
int msm_gem_get_iova_locked(struct drm_gem_object *obj, int id,
^
Signed-off-by: Matwey V. Kornilov
---
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index a752ab8..5107fc4 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -59,7 +59,7 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,
struct drm_framebuffer *fb = NULL;
struct fb_info *fbi = NULL;
struct drm_mode_fb_cmd2 mode_cmd = {0};
- dma_addr_t paddr;
+ uint32_t paddr;
int ret, size;
sizes->surface_bpp = 32;
--
1.9.3
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Export functions from pcie-designware
2014-08-30 17:07 GMT+04:00 Fabio Estevam : > On Sat, Aug 30, 2014 at 9:24 AM, wrote: >> +EXPORT_SYMBOL(dw_pcie_cfg_read); > > What about using EXPORT_SYMBOL_GPL instead? It is for initial author to decide whether he want to export this function only for GPLed. > Why is this needed? For style consistency, I believe. -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 2/2] parport: parport_pc: Implement CPU model check to cut off false-positives
Hi,
What do you think, would it be better just to left the check for all
x86 32-bit hardware?.
2014-07-18 11:31 GMT+04:00 Ondrej Zary :
> On Friday 18 July 2014, mat...@sai.msu.ru wrote:
>> From: "Matwey V. Kornilov"
>>
>> The code in intel_bug_present is known to produce much false-positives.
>> It is believed that the affected by the bug hardware are used with either
>> Intel 80486 or Pentium.
>>
>> Perform the check only when the kernel configured as CONFIG_X86_32,
>> then use cpuinfo_x86 of the first available CPU to check the model
>> and run initial check code.
>>
>> Suggested-by: One Thousand Gnomes
>> Tested-by: Heiko Andreas Sommer
>> Signed-off-by: Matwey V. Kornilov
>> ---
>> drivers/parport/parport_pc.c | 21 -
>> 1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
>> index a6eaafb..6b28f9f 100644
>> --- a/drivers/parport/parport_pc.c
>> +++ b/drivers/parport/parport_pc.c
>> @@ -65,6 +65,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #define PARPORT_PC_MAX_PORTS PARPORT_MAX
>>
>> @@ -1702,7 +1703,11 @@ static int parport_ECP_supported(struct parport *pb)
>> }
>> #endif
>>
>> -static int intel_bug_present(struct parport *pb)
>> +/* It is believed that CPU model correlates with buggy LPT chipset model.
>> +Here we check that or CPU is elder than Pentium Pro: either 80486 or
>> Pentium. +If it is then we perform The Check. */
>> +#ifdef CONFIG_X86_32
>> +static int intel_bug_present_check_epp(struct parport *pb)
>> {
>> const struct parport_pc_private *priv = pb->private_data;
>> int bug_present = 0;
>> @@ -1725,6 +1730,20 @@ static int intel_bug_present(struct parport *pb)
>>
>> return bug_present;
>> }
>> +static int intel_bug_present(struct parport *pb)
>> +{
>> + struct cpuinfo_x86 *c = &cpu_data(0);
>> +
>> + if (c->x86_vendor == X86_VENDOR_INTEL && (c->x86 == 4 || c->x86 == 5))
>> + return intel_bug_present_check_epp(pb);
>
> You can have a non-Intel CPU in a 486 or Pentium board.
>
>> + return 0;
>> +}
>> +#else
>> +static int intel_bug_present(struct parport *pb)
>> +{
>> + return 0;
>> +}
>> +#endif
>>
>> static int parport_ECPPS2_supported(struct parport *pb)
>> {
>
>
>
> --
> Ondrej Zary
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Restrict TSC test code to x86
28.10.2014 16:12, Alexander Graf пишет:
>
>
>
>> Am 28.10.2014 um 13:47 schrieb Jonathan Corbet :
>>
>> On Mon, 27 Oct 2014 20:07:51 -0400
>> Peter Foley wrote:
>>
The prctl test code in Documentation/ tries to show how to
use a call that only makes sense on x86. Restrict it there
so that other platforms don't try to call asm("rdtsc").
Signed-off-by: Alexander Graf
>>>
>>> Acked-by: Peter Foley
>>
>> Snagged into the docs tree, thanks.
>
> Awesome, please make sure this makes it into 3.18 - the build is broken on
> non-x86 archs there ;).
>
> Alex
>
Hi,
Sorry for criticism, but the patch is not complete.
CONFIG_X86 deals with target architecture, at the same time the problem
deals with the host architecture.
Imagine, that I run arm, aarch64 or something else and do
cross-compiling kernel for x86 on it. Then CONFIG_X86 will evaluate to
'y' and make will try to compile the apps with the host-compiler, which
is not x86 one.
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Restrict TSC test code to x86
I wish I knew. We need KBuild guru to ask how to take into account
host architecture.
2014-11-02 0:16 GMT+03:00 Alexander Graf :
>
>
> On 01.11.14 13:03, Matwey V. Kornilov wrote:
>> 28.10.2014 16:12, Alexander Graf пишет:
>>>
>>>
>>>
>>>> Am 28.10.2014 um 13:47 schrieb Jonathan Corbet :
>>>>
>>>> On Mon, 27 Oct 2014 20:07:51 -0400
>>>> Peter Foley wrote:
>>>>
>>>>>> The prctl test code in Documentation/ tries to show how to
>>>>>> use a call that only makes sense on x86. Restrict it there
>>>>>> so that other platforms don't try to call asm("rdtsc").
>>>>>>
>>>>>> Signed-off-by: Alexander Graf
>>>>>
>>>>> Acked-by: Peter Foley
>>>>
>>>> Snagged into the docs tree, thanks.
>>>
>>> Awesome, please make sure this makes it into 3.18 - the build is broken on
>>> non-x86 archs there ;).
>>>
>>> Alex
>>>
>>
>> Hi,
>>
>> Sorry for criticism, but the patch is not complete.
>> CONFIG_X86 deals with target architecture, at the same time the problem
>> deals with the host architecture.
>>
>> Imagine, that I run arm, aarch64 or something else and do
>> cross-compiling kernel for x86 on it. Then CONFIG_X86 will evaluate to
>> 'y' and make will try to compile the apps with the host-compiler, which
>> is not x86 one.
>
> Good point. Any ideas how I can easily limit this to x86 hosts?
>
>
> Alex
--
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: Restrict TSC test code to x86
I've added Yann and Michal to the discussion. The issue is that we have hostprogs-y := disable-tsc-ctxt-sw-stress-test disable-tsc-on-off-stress-test disable-tsc-test in Documentation/prctl/Makefile and disable-tsc-ctxt-sw-stress-test has x86 assembler inside and must be restricted only to this host architecture. 2014-11-02 11:16 GMT+03:00 Alexander Graf : > > > On 02.11.14 08:46, Matwey V. Kornilov wrote: >> I wish I knew. We need KBuild guru to ask how to take into account >> host architecture. > > Hrm. At least this patch makes things more consistent with the other > Documentation makefiles: > > Documentation/timers/Makefile:hostprogs-$(CONFIG_X86) := hpet_example > Documentation/vDSO/Makefile:hostprogs-$(CONFIG_X86) := > vdso_standalone_test_x86 > > But I agree, it is wrong in general - hostprogs should make sure the > host arch matches. > > We could maybe just evaluate the host uname output: > > ifeq ($(shell uname -m),x86_64) > hostprogs-$(CONFIG_X86) := ... > endif > > Then we're double safe ;). Not sure how to easily add x86 to the mix as > well here, but I'm not sure anyone cares. Do people still compile on > 32bit x86 hosts? And expect Documentation/ examples to build? > > > Alex -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp://0x2...@jabber.ru -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 8250: Hypervisors always export working 16550A UARTs.
2016-04-29 1:18 GMT+03:00 Richard W.M. Jones : > [This is an opinionated patch, mainly for discussion.] > > I'm trying to reduce the time taken in the kernel in initcalls, with > my aim being to reduce the current ~700ms spent in initcalls before > userspace, down to something like 100ms. All times on my Broadwell-U > laptop, under virtualization. The purpose of this is to be able to > launch VMs around containers with minimal overhead, like Intel Clear > Containers, but using standard distro kernels and qemu. > > Currently the kernel spends 25ms inspecting the UART that we passed to > it from qemu to find out whether it's an 8250/16550/16550A perhaps > with a non-working FIFO or other quirks. Well, it isn't -- it's a > working emulated 16550A, with a FIFO and no quirks, and if it isn't, > we should fix qemu. > > So the patch detects if we're running virtualized (perhaps it should > only check for qemu/KVM?) and if so, shortcuts the tests. Does anybody know, whether it is possible to pass through real hardware serial port to a guest? It seems to be as simple as to pass through an interrupt and memory IO ports. > > Rich. > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
Re: [PATCH v2 3/3] tty: Add software emulated RS485 support for 8250
2015-11-10 19:12 GMT+03:00 Peter Hurley :
> Hi Matwey,
>
> I noticed 3 other issues here; see below.
>
> On 11/07/2015 05:09 AM, Matwey V. Kornilov wrote:
>> Implementation of software emulation of RS485 direction handling is based
>> on omap-serial driver. It is acts as the following. At transmission start,
>> RTS is set (if required) and receiver is off (if required). At transmission
>> stop, RTS is set (if required) and fifo is flushed.
>>
>> Signed-off-by: Matwey V. Kornilov
>> ---
>> drivers/tty/serial/8250/8250_port.c | 32
>> 1 file changed, 32 insertions(+)
>>
>> diff --git a/drivers/tty/serial/8250/8250_port.c
>> b/drivers/tty/serial/8250/8250_port.c
>> index 52d82d2..a9291f7 100644
>> --- a/drivers/tty/serial/8250/8250_port.c
>> +++ b/drivers/tty/serial/8250/8250_port.c
>> @@ -559,7 +559,37 @@ static void serial8250_rpm_put_tx(struct uart_8250_port
>> *p)
>> pm_runtime_mark_last_busy(p->port.dev);
>> pm_runtime_put_autosuspend(p->port.dev);
>> }
>> +static void serial8250_stop_rx(struct uart_port *port);
>> +static void serial8250_rs485_start_tx(struct uart_8250_port *p)
>> +{
>> + if (p->capabilities & UART_CAP_HW485 || !(p->port.rs485.flags &
>> SER_RS485_ENABLED))
>> + return;
>> +
>> + if (p->port.rs485.flags & SER_RS485_RTS_ON_SEND) {
>> + serial_port_out(&p->port, UART_MCR, UART_MCR_RTS);
>
> The SER_RS485_RTS_ON_SEND bit is supposed to be the logic level of RTS,
> so RTS should be driven to either 0 or 1 here (not just to 1).
By the way, I've found that p->mcr caches MCR inconsistently. Is it
supposed to be so? Or p->mcr is not for caching?
>
>> + if (p->port.rs485.delay_rts_before_send > 0)
>> + mdelay(p->port.rs485.delay_rts_before_send);
>> + }
>> + if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX))
>> + serial8250_stop_rx(&p->port);
>> +}
>> +static void serial8250_rs485_stop_tx(struct uart_8250_port *p)
>> +{
>> + if (p->capabilities & UART_CAP_HW485 || !(p->port.rs485.flags &
>> SER_RS485_ENABLED))
>> + return;
>
> Unlike omap-serial, the 8250 stop_tx() will trigger _before_ the transmitter
> is drained. Some mechanism is required to defer until the transmitter
> is empty.
>
>> + if (p->port.rs485.flags & SER_RS485_RTS_AFTER_SEND) {
>> + if (p->port.rs485.delay_rts_after_send > 0)
>> + mdelay(p->port.rs485.delay_rts_after_send);
>> + serial_port_out(&p->port, UART_MCR, UART_MCR_RTS);
>
> As with the SER_RS485_RTS_ON_SEND, RTS should be driven to either 0 or 1 here
> as well (not just to 1).
>
> Regards,
> Peter Hurley
>
>> + }
>> + /*
>> + * Empty the RX FIFO, we are not interested in anything
>> + * received during the half-duplex transmission.
>> + */
>> + if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX))
>> + serial8250_clear_fifos(p);
>> +}
>> /*
>> * IER sleep support. UARTs which have EFRs need the "extended
>> * capability" bit enabled. Note that on XR16C850s, we need to
>> @@ -1309,6 +1339,7 @@ static void serial8250_stop_tx(struct uart_port *port)
>> up->acr |= UART_ACR_TXDIS;
>> serial_icr_write(up, UART_ACR, up->acr);
>> }
>> + serial8250_rs485_stop_tx(up);
>> serial8250_rpm_put(up);
>> }
>>
>> @@ -1317,6 +1348,7 @@ static void serial8250_start_tx(struct uart_port *port)
>> struct uart_8250_port *up = up_to_u8250p(port);
>>
>> serial8250_rpm_get_tx(up);
>> + serial8250_rs485_start_tx(up);
>>
>> if (up->dma && !up->dma->tx_dma(up))
>> return;
>>
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/5] tty: Introduce software RS485 direction control support
Changes from v2: - Introduced SER_RS485_SOFTWARE to show that software implementation is being used - serial8250_rs485_config is located as required - Timers are used to implement delay_before and delay_after timeouts -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/5] tty: Add software emulated RS485 support for 8250
Implementation of software emulation of RS485 direction handling is based
on omap-serial driver.
Before and after transmission RTS is set to the appropriate value.
Signed-off-by: Matwey V. Kornilov
---
drivers/tty/serial/8250/8250_port.c | 152 ++--
include/linux/serial_8250.h | 2 +
2 files changed, 148 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index 3f6d8a2..b863a12 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1299,7 +1300,75 @@ static void serial8250_stop_rx(struct uart_port *port)
serial8250_rpm_put(up);
}
-static inline void __stop_tx(struct uart_8250_port *p)
+static inline void serial8250_rs485_set_rts_on_send(struct uart_8250_port *p)
+{
+ if (p->port.rs485.flags & SER_RS485_RTS_ON_SEND)
+ p->mcr |= UART_MCR_RTS;
+ else
+ p->mcr &= ~UART_MCR_RTS;
+ serial_out(p, UART_MCR, p->mcr);
+}
+
+static inline void serial8250_rs485_set_rts_after_send(struct uart_8250_port
*p)
+{
+ if (p->port.rs485.flags & SER_RS485_RTS_AFTER_SEND)
+ p->mcr |= UART_MCR_RTS;
+ else
+ p->mcr &= ~UART_MCR_RTS;
+ serial_out(p, UART_MCR, p->mcr);
+}
+
+static __u32 serial8250_rs485_start_tx(struct uart_8250_port *p)
+{
+ if (p->capabilities & UART_CAP_HW485 || !(p->port.rs485.flags &
SER_RS485_ENABLED))
+ return 0;
+
+ if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX))
+ serial8250_stop_rx(&p->port);
+
+ del_timer_sync(&p->rs485_stop_tx_timer);
+
+ if (!!(p->port.rs485.flags & SER_RS485_RTS_ON_SEND) != !!(p->mcr &
UART_MCR_RTS)) {
+ serial8250_rs485_set_rts_on_send(p);
+ return p->port.rs485.delay_rts_before_send;
+ }
+
+ return 0;
+}
+
+static inline void __do_stop_tx_rs485(struct uart_8250_port *p)
+{
+ serial8250_rs485_set_rts_after_send(p);
+ /*
+ * Empty the RX FIFO, we are not interested in anything
+ * received during the half-duplex transmission.
+ */
+ if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX))
+ serial8250_clear_fifos(p);
+}
+
+static void serial8250_handle_rs485_stop_tx_timer(unsigned long arg)
+{
+ struct uart_8250_port *p = (struct uart_8250_port*)arg;
+ __do_stop_tx_rs485(p);
+}
+
+static inline void __stop_tx_rs485(struct uart_8250_port *p)
+{
+ if (p->capabilities & UART_CAP_HW485 || !(p->port.rs485.flags &
SER_RS485_ENABLED))
+ return;
+
+ del_timer_sync(&p->rs485_start_tx_timer);
+
+ /* __do_stop_tx_rs485 is going to set RTS according to config AND flush
RX FIFO if required */
+ if (p->port.rs485.delay_rts_after_send > 0) {
+ mod_timer(&p->rs485_stop_tx_timer, jiffies +
p->port.rs485.delay_rts_after_send * HZ / 1000);
+ } else {
+ __do_stop_tx_rs485(p);
+ }
+}
+
+static inline void __do_stop_tx(struct uart_8250_port *p)
{
if (p->ier & UART_IER_THRI) {
p->ier &= ~UART_IER_THRI;
@@ -1308,6 +1377,12 @@ static inline void __stop_tx(struct uart_8250_port *p)
}
}
+static inline void __stop_tx(struct uart_8250_port *p)
+{
+ __do_stop_tx(p);
+ __stop_tx_rs485(p);
+}
+
static void serial8250_stop_tx(struct uart_port *port)
{
struct uart_8250_port *up = up_to_u8250p(port);
@@ -1325,12 +1400,10 @@ static void serial8250_stop_tx(struct uart_port *port)
serial8250_rpm_put(up);
}
-static void serial8250_start_tx(struct uart_port *port)
+static inline void __start_tx(struct uart_port* port)
{
struct uart_8250_port *up = up_to_u8250p(port);
- serial8250_rpm_get_tx(up);
-
if (up->dma && !up->dma->tx_dma(up))
return;
@@ -1356,6 +1429,29 @@ static void serial8250_start_tx(struct uart_port *port)
}
}
+static void serial8250_handle_rs485_start_tx_timer(unsigned long arg)
+{
+ struct uart_port* port = (struct uart_port*)arg;
+ __start_tx(port);
+}
+
+static void serial8250_start_tx(struct uart_port *port)
+{
+ struct uart_8250_port *up = up_to_u8250p(port);
+ __u32 delay;
+
+ serial8250_rpm_get_tx(up);
+
+ if (timer_pending(&up->rs485_start_tx_timer))
+ return;
+
+ if ((delay = serial8250_rs485_start_tx(up))) {
+ mod_timer(&up->rs485_start_tx_timer, jiffies + delay * HZ /
1000);
+ } else {
+ __start_tx(port);
+ }
+}
+
static void serial8250_throttle(struct uart_port *port)
{
port->throttle(port);
@@ -18
[PATCH v3 3/5] tty: Implement default fallback serial8250_rs485_config
When 8250 driver doesn't have its own hardware RS485 support and doesn't
want to override rs485_config callback, then default
serial8250_rs485_config is used. It just stores supplied by user-space
config and sets SER_RS485_SOFTWARE
Signed-off-by: Matwey V. Kornilov
---
drivers/tty/serial/8250/8250_core.c | 3 ++-
drivers/tty/serial/8250/8250_port.c | 10 ++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 3912646..71fabb0 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -986,7 +986,6 @@ int serial8250_register_8250_port(struct uart_8250_port *up)
uart->capabilities = up->capabilities;
uart->port.throttle = up->port.throttle;
uart->port.unthrottle = up->port.unthrottle;
- uart->port.rs485_config = up->port.rs485_config;
uart->port.rs485= up->port.rs485;
uart->dma = up->dma;
@@ -1025,6 +1024,8 @@ int serial8250_register_8250_port(struct uart_8250_port
*up)
uart->port.pm = up->port.pm;
if (up->port.handle_break)
uart->port.handle_break = up->port.handle_break;
+ if (up->port.rs485_config)
+ uart->port.rs485_config = up->port.rs485_config;
if (up->dl_read)
uart->dl_read = up->dl_read;
if (up->dl_write)
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index 52d82d2..067ef55 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2735,6 +2735,14 @@ serial8250_type(struct uart_port *port)
return uart_config[type].name;
}
+static int serial8250_rs485_config(struct uart_port *port,
+ struct serial_rs485 *rs485)
+{
+ port->rs485 = *rs485;
+ port->rs485.flags |= SER_RS485_SOFTWARE;
+ return 0;
+}
+
static const struct uart_ops serial8250_pops = {
.tx_empty = serial8250_tx_empty,
.set_mctrl = serial8250_set_mctrl,
@@ -2797,6 +2805,8 @@ void serial8250_set_defaults(struct uart_8250_port *up)
if (!up->dma->rx_dma)
up->dma->rx_dma = serial8250_rx_dma;
}
+
+ up->port.rs485_config = serial8250_rs485_config;
}
EXPORT_SYMBOL_GPL(serial8250_set_defaults);
--
2.6.2
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485
This flag is supposed to be used by uart drivers using software rs485 direction
control.
Signed-off-by: Matwey V. Kornilov
---
include/uapi/linux/serial.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/serial.h b/include/uapi/linux/serial.h
index 25331f9..95b15ca 100644
--- a/include/uapi/linux/serial.h
+++ b/include/uapi/linux/serial.h
@@ -121,6 +121,9 @@ struct serial_rs485 {
#define SER_RS485_RTS_AFTER_SEND (1 << 2)/* Logical level for
RTS pin after sent*/
#define SER_RS485_RX_DURING_TX (1 << 4)
+#define SER_RS485_SOFTWARE (1 << 5)/* Software
+ implementation is
+ being used */
__u32 delay_rts_before_send; /* Delay before send (milliseconds) */
__u32 delay_rts_after_send; /* Delay after send (milliseconds) */
__u32 padding[5]; /* Memory is cheap, new structs
--
2.6.2
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/5] tty: Move serial8250_stop_rx in front of serial8250_start_tx
Signed-off-by: Matwey V. Kornilov
---
drivers/tty/serial/8250/8250_port.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index 067ef55..3f6d8a2 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1286,6 +1286,19 @@ static void autoconfig_irq(struct uart_8250_port *up)
port->irq = (irq > 0) ? irq : 0;
}
+static void serial8250_stop_rx(struct uart_port *port)
+{
+ struct uart_8250_port *up = up_to_u8250p(port);
+
+ serial8250_rpm_get(up);
+
+ up->ier &= ~(UART_IER_RLSI | UART_IER_RDI);
+ up->port.read_status_mask &= ~UART_LSR_DR;
+ serial_port_out(port, UART_IER, up->ier);
+
+ serial8250_rpm_put(up);
+}
+
static inline void __stop_tx(struct uart_8250_port *p)
{
if (p->ier & UART_IER_THRI) {
@@ -1353,19 +1366,6 @@ static void serial8250_unthrottle(struct uart_port *port)
port->unthrottle(port);
}
-static void serial8250_stop_rx(struct uart_port *port)
-{
- struct uart_8250_port *up = up_to_u8250p(port);
-
- serial8250_rpm_get(up);
-
- up->ier &= ~(UART_IER_RLSI | UART_IER_RDI);
- up->port.read_status_mask &= ~UART_LSR_DR;
- serial_port_out(port, UART_IER, up->ier);
-
- serial8250_rpm_put(up);
-}
-
static void serial8250_disable_ms(struct uart_port *port)
{
struct uart_8250_port *up =
--
2.6.2
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/5] tty: Introduce UART_CAP_HW485
Introduce new capability UART_CAP_HW485 to mark 8250 UARTs which have
hardware support of line direction control.
Signed-off-by: Matwey V. Kornilov
---
drivers/tty/serial/8250/8250.h | 1 +
drivers/tty/serial/8250/8250_fintek.c | 1 +
drivers/tty/serial/8250/8250_lpc18xx.c | 1 +
drivers/tty/serial/8250/8250_pci.c | 1 +
4 files changed, 4 insertions(+)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index d54dcd8..92a4f47 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -69,6 +69,7 @@ struct serial8250_config {
unsigned intflags;
};
+#define UART_CAP_HW485 (1 << 7)/* UART has hardware direction control
for RS485 */
#define UART_CAP_FIFO (1 << 8)/* UART has FIFO */
#define UART_CAP_EFR (1 << 9)/* UART has EFR */
#define UART_CAP_SLEEP (1 << 10) /* UART has IER sleep */
diff --git a/drivers/tty/serial/8250/8250_fintek.c
b/drivers/tty/serial/8250/8250_fintek.c
index 8947439..f2831a8 100644
--- a/drivers/tty/serial/8250/8250_fintek.c
+++ b/drivers/tty/serial/8250/8250_fintek.c
@@ -208,6 +208,7 @@ fintek_8250_probe(struct pnp_dev *dev, const struct
pnp_device_id *dev_id)
uart.port.iobase = pnp_port_start(dev, 0);
uart.port.iotype = UPIO_PORT;
uart.port.rs485_config = fintek_8250_rs485_config;
+ uart.capabilities = UART_CAP_HW485;
uart.port.flags |= UPF_SKIP_TEST | UPF_BOOT_AUTOCONF;
if (pnp_irq_flags(dev, 0) & IORESOURCE_IRQ_SHAREABLE)
diff --git a/drivers/tty/serial/8250/8250_lpc18xx.c
b/drivers/tty/serial/8250/8250_lpc18xx.c
index 99cd478..9d30276 100644
--- a/drivers/tty/serial/8250/8250_lpc18xx.c
+++ b/drivers/tty/serial/8250/8250_lpc18xx.c
@@ -175,6 +175,7 @@ static int lpc18xx_serial_probe(struct platform_device
*pdev)
uart.port.private_data = data;
uart.port.rs485_config = lpc18xx_rs485_config;
uart.port.serial_out = lpc18xx_uart_serial_out;
+ uart.capabilities = UART_CAP_HW485;
uart.dma = &data->dma;
uart.dma->rxconf.src_maxburst = 1;
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index 4097f3f..c7c0ae9 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1599,6 +1599,7 @@ static int pci_fintek_setup(struct serial_private *priv,
port->port.iotype = UPIO_PORT;
port->port.iobase = iobase;
port->port.rs485_config = pci_fintek_rs485_config;
+ port->capabilities = UART_CAP_HW485;
data = devm_kzalloc(&pdev->dev, sizeof(u8), GFP_KERNEL);
if (!data)
--
2.6.2
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] tty: Add software emulated RS485 support for 8250
2015-11-12 16:35 GMT+03:00 Peter Hurley :
> On 11/12/2015 07:34 AM, Matwey V. Kornilov wrote:
>> 2015-11-10 19:12 GMT+03:00 Peter Hurley :
>>> On 11/07/2015 05:09 AM, Matwey V. Kornilov wrote:
>>>> Implementation of software emulation of RS485 direction handling is based
>>>> on omap-serial driver. It is acts as the following. At transmission start,
>>>> RTS is set (if required) and receiver is off (if required). At transmission
>>>> stop, RTS is set (if required) and fifo is flushed.
>>>>
>>>> Signed-off-by: Matwey V. Kornilov
>>>> ---
>>>> drivers/tty/serial/8250/8250_port.c | 32
>>>> 1 file changed, 32 insertions(+)
>>>>
>>>> diff --git a/drivers/tty/serial/8250/8250_port.c
>>>> b/drivers/tty/serial/8250/8250_port.c
>>>> index 52d82d2..a9291f7 100644
>>>> --- a/drivers/tty/serial/8250/8250_port.c
>>>> +++ b/drivers/tty/serial/8250/8250_port.c
>>>> @@ -559,7 +559,37 @@ static void serial8250_rpm_put_tx(struct
>>>> uart_8250_port *p)
>>>> pm_runtime_mark_last_busy(p->port.dev);
>>>> pm_runtime_put_autosuspend(p->port.dev);
>>>> }
>>>> +static void serial8250_stop_rx(struct uart_port *port);
>>>> +static void serial8250_rs485_start_tx(struct uart_8250_port *p)
>>>> +{
>>>> + if (p->capabilities & UART_CAP_HW485 || !(p->port.rs485.flags &
>>>> SER_RS485_ENABLED))
>>>> + return;
>>>> +
>>>> + if (p->port.rs485.flags & SER_RS485_RTS_ON_SEND) {
>>>> + serial_port_out(&p->port, UART_MCR, UART_MCR_RTS);
>>>
>>> The SER_RS485_RTS_ON_SEND bit is supposed to be the logic level of RTS,
>>> so RTS should be driven to either 0 or 1 here (not just to 1).
>>
>> By the way, I've found that p->mcr caches MCR inconsistently. Is it
>> supposed to be so? Or p->mcr is not for caching?
>
> Not for caching; it's for modal settings (eg., AFE) that the 8250 port
> driver needs to merge in when changing mctrl bits (DTR/RTS/etc).
>
> The serial core caches the mctrl bits in uart_port->mctrl, but IMO
> it would be simpler to always set/clear RTS here (rather than like
> the omap-serial driver where it checks the gpio value first).
>
> Is the assumption that userspace will not perform conflicting
> operations, such as ioctl(TIOCMSET) or ioctl(TCSETSx), with RS485 enabled?
I've sent v3 series and put all RTS related stuff into separate
functions. Could you please continue this discussion in "v3 5/5"?
TIOCMGET should work correctly now, because it reads register. I am
not sure that TIOCMSET should be limited somehow, user knows better
what he wants.
> Regards,
> Peter Hurley
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485
2015-11-12 22:57 GMT+03:00 One Thousand Gnomes :
> On Thu, 12 Nov 2015 17:33:53 +0300
> "Matwey V. Kornilov" wrote:
>
>> This flag is supposed to be used by uart drivers using software rs485
>> direction control.
>>
>> Signed-off-by: Matwey V. Kornilov
>> ---
>> include/uapi/linux/serial.h | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/include/uapi/linux/serial.h b/include/uapi/linux/serial.h
>> index 25331f9..95b15ca 100644
>> --- a/include/uapi/linux/serial.h
>> +++ b/include/uapi/linux/serial.h
>> @@ -121,6 +121,9 @@ struct serial_rs485 {
>> #define SER_RS485_RTS_AFTER_SEND (1 << 2)/* Logical level for
>> RTS pin after sent*/
>> #define SER_RS485_RX_DURING_TX (1 << 4)
>> +#define SER_RS485_SOFTWARE (1 << 5)/* Software
>> +implementation is
>> +being used */
>
> I've only got one question here - why do we need this flag. Why does the
> application care whether the timer is in the kernel or in the chip. In
> particular think about cases where some combinations of features require
> software fallback and others don't. What would the flag indicate then.
>
Peter asked for it, I respect his experience.
Only two lines are required to implement this, so it is easy to add,
easy to drop.
> The patches look nice but I'd strongly favour not having a software flag.
> It should never matter as the kernel API is the same in all cases and we
> should therefore discourage application code from trying to know things
> it doesn't need to worry about.
>
> Alan
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485
2015-12-03 22:45 GMT+03:00 Peter Hurley : > On 12/03/2015 12:29 PM, Matwey V. Kornilov wrote: >> 2015-12-03 17:41 GMT+03:00 Peter Hurley : >>> Hi Matwey, >>> >>> On 12/03/2015 12:50 AM, Matwey V. Kornilov wrote: >>>> I am working on v4, where I completely redesigned implementation. And >>>> now I think that it is considerably better than v3. >>>> It looks like the following: >>>> https://github.com/matwey/linux/commits/8520_rs485_v4 >>>> But it is not ready yet, there is a bug somewhere. >>>> >>>> In the v4, each subdriver decides separately if it needs rs485 >>>> emulation support. Then it enables it like the following: >>>> https://github.com/matwey/linux/commit/4455e425fc045713fb921ccec695fe183f1558f0 >>>> Before calling serial8250_rs485_emul_enabled, the driver enables >>>> interrupt on empty shift register (they are always there for omap_). >>> >>> Looks good. >>> >>> Are you testing with CONFIG_SERIAL_8250_DMA=n first to simplify the >>> debug effort? DMA adds a completely different tx path. >> >> Many thanks for the advice. I've just found that the bug is not in my code =) >> Even with pure 4.3.0 I cannot open /dev/ttyS5 more than once. It just >> hangs on open() and the process is in S+ state. > > Hmm, that's odd. So > > $ stty -a < /dev/ttyS5 > > hangs if something like below is running? > > $ cat > /dev/ttyS5 > Nonblocking mode works, blocking mode hands on tty_port_block_til_ready https://bugzilla.kernel.org/show_bug.cgi?id=108851 > >>> Also, before submission, please shorten the identifiers. And Greg hates >>> functions returning bool so just expanded serial8250_rs485_emul_enabled() >>> inline. I would like to keep it as API to hide implementation details. In other words, I don't want to inline it in omap_8250_rs485_config. >> >> Am I allowed to use `re' instead of rs485_emul in names? > > Long names and constructs tend to obscure the execution flow. > Some of the names could be reduced where the meaning is obvious: > > serial8250_rts_on_send > serial8250_rts_after_send > serial8250_handle_start_timer > serial8250_handle_stop_timer > > These two I would inline into their lone call site: > > serial8250_rs485_emul_startup() > serial8250_rs485_emul_shutdown() > > serial8250_rs485_emul_start_tx => __start_tx_rs485 > > rs485_emul => sw485/em485/emul485/soft485 ? > > Or just rs485 (except for the field name and structs so as not to confuse > it with the port->rs485) > > Just my 2¢ > > Regards, > Peter Hurley > > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tty: Introduce software RS485 direction control support
Changes from v3: - Completely redesigned. Changes from v2: - Introduced SER_RS485_SOFTWARE to show that software implementation is being used - serial8250_rs485_config is located as required - Timers are used to implement delay_before and delay_after timeouts -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/3] tty: Add software emulated RS485 support for 8250
Implementation of software emulation of RS485 direction handling is based
on omap_serial driver.
Before and after transmission RTS is set to the appropriate value.
Note that before calling serial8250_em485_init the caller has to
ensure that UART will interrupt when shift register empty. Otherwise,
emultaion cannot be used.
Both serial8250_em485_init and serial8250_em485_destroy are
idempotent functions.
Signed-off-by: Matwey V. Kornilov
---
drivers/tty/serial/8250/8250.h | 6 ++
drivers/tty/serial/8250/8250_port.c | 161 +++-
include/linux/serial_8250.h | 7 ++
3 files changed, 170 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index d54dcd8..a3816c6 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -117,6 +117,12 @@ static inline void serial_dl_write(struct uart_8250_port
*up, int value)
struct uart_8250_port *serial8250_get_port(int line);
void serial8250_rpm_get(struct uart_8250_port *p);
void serial8250_rpm_put(struct uart_8250_port *p);
+int serial8250_em485_init(struct uart_8250_port *p);
+void serial8250_em485_destroy(struct uart_8250_port *p);
+static inline bool serial8250_em485_enabled(struct uart_8250_port *p)
+{
+ return p->rs485_emul && (p->port.rs485.flags & SER_RS485_ENABLED);
+}
#if defined(__alpha__) && !defined(CONFIG_PCI)
/*
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index 8ad0b2d..394d0d2 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
@@ -504,6 +505,31 @@ static void serial8250_clear_fifos(struct uart_8250_port
*p)
}
}
+static inline void serial8250_em485_rts_on_send(struct uart_8250_port *p)
+{
+ unsigned char mcr = serial_in(p, UART_MCR);
+
+ if (p->port.rs485.flags & SER_RS485_RTS_ON_SEND)
+ mcr |= UART_MCR_RTS;
+ else
+ mcr &= ~UART_MCR_RTS;
+ serial_out(p, UART_MCR, mcr);
+}
+
+static inline void serial8250_em485_rts_after_send(struct uart_8250_port *p)
+{
+ unsigned char mcr = serial_in(p, UART_MCR);
+
+ if (p->port.rs485.flags & SER_RS485_RTS_AFTER_SEND)
+ mcr |= UART_MCR_RTS;
+ else
+ mcr &= ~UART_MCR_RTS;
+ serial_out(p, UART_MCR, mcr);
+}
+
+static void serial8250_em485_handle_start_tx(unsigned long arg);
+static void serial8250_em485_handle_stop_tx(unsigned long arg);
+
void serial8250_clear_and_reinit_fifos(struct uart_8250_port *p)
{
serial8250_clear_fifos(p);
@@ -528,6 +554,42 @@ void serial8250_rpm_put(struct uart_8250_port *p)
}
EXPORT_SYMBOL_GPL(serial8250_rpm_put);
+int serial8250_em485_init(struct uart_8250_port *p)
+{
+ if (p->rs485_emul != NULL)
+ return 0;
+
+ p->rs485_emul = kmalloc(sizeof(struct uart_8250_rs485_emul),
GFP_KERNEL);
+ if (p->rs485_emul == NULL)
+ return -ENOMEM;
+
+ init_timer(&p->rs485_emul->stop_tx_timer);
+ p->rs485_emul->stop_tx_timer.function = serial8250_em485_handle_stop_tx;
+ p->rs485_emul->stop_tx_timer.data = (unsigned long)p;
+ p->rs485_emul->stop_tx_timer.flags |= TIMER_IRQSAFE;
+ init_timer(&p->rs485_emul->start_tx_timer);
+ p->rs485_emul->start_tx_timer.function =
serial8250_em485_handle_start_tx;
+ p->rs485_emul->start_tx_timer.data = (unsigned long)p;
+ p->rs485_emul->start_tx_timer.flags |= TIMER_IRQSAFE;
+
+ serial8250_em485_rts_after_send(p);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(serial8250_em485_init);
+void serial8250_em485_destroy(struct uart_8250_port *p)
+{
+ if (p->rs485_emul == NULL)
+ return;
+
+ del_timer_sync(&p->rs485_emul->start_tx_timer);
+ del_timer_sync(&p->rs485_emul->stop_tx_timer);
+
+ kfree(p->rs485_emul);
+ p->rs485_emul = NULL;
+}
+EXPORT_SYMBOL_GPL(serial8250_em485_destroy);
+
/*
* These two wrappers ensure that enable_runtime_pm_tx() can be called more
than
* once and disable_runtime_pm_tx() will still disable RPM because the fifo is
@@ -1293,7 +1355,61 @@ static void serial8250_stop_rx(struct uart_port *port)
serial8250_rpm_put(up);
}
-static inline void __stop_tx(struct uart_8250_port *p)
+static __u32 __start_tx_rs485(struct uart_8250_port *p)
+{
+ if (!serial8250_em485_enabled(p))
+ return 0;
+
+ if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX))
+ serial8250_stop_rx(&p->port);
+
+ del_timer_sync(&p->rs485_emul->stop_tx_timer);
+
+ if (!!(p->port.rs485.flags & SER_RS485_RTS_ON_SEND) != !!(serial_in(p,
UART_MCR) & UART_MCR_RTS)) {
+
[PATCH v4 3/3] tty: 8250_omap: Use software emulated RS485 direction control
Use software emulated RS485 direction control to provide RS485 API existed in
omap_serial driver. Note that 8250_omap issues interrupt on shift register
empty which is single prerequesite for using software emulated RS485.
Signed-off-by: Matwey V. Kornilov
---
drivers/tty/serial/8250/8250_omap.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 826c5c4..323c0a4 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -698,6 +698,23 @@ static void omap_8250_throttle(struct uart_port *port)
pm_runtime_put_autosuspend(port->dev);
}
+static int omap_8250_rs485_config(struct uart_port *port, struct serial_rs485
*rs485)
+{
+ struct uart_8250_port *up = up_to_u8250p(port);
+
+ if (rs485->flags & SER_RS485_ENABLED && !serial8250_em485_enabled(up)) {
+ port->rs485 = *rs485;
+ return serial8250_em485_init(up);
+ }
+
+ if (serial8250_em485_enabled(up) && !(rs485->flags & SER_RS485_ENABLED))
+ serial8250_em485_destroy(up);
+
+ port->rs485 = *rs485;
+
+ return 0;
+}
+
static void omap_8250_unthrottle(struct uart_port *port)
{
unsigned long flags;
@@ -1144,6 +1161,7 @@ static int omap8250_probe(struct platform_device *pdev)
up.port.shutdown = omap_8250_shutdown;
up.port.throttle = omap_8250_throttle;
up.port.unthrottle = omap_8250_unthrottle;
+ up.port.rs485_config = omap_8250_rs485_config;
if (pdev->dev.of_node) {
const struct of_device_id *id;
--
2.6.3
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/3] tty: Move serial8250_stop_rx in front of serial8250_start_tx
Signed-off-by: Matwey V. Kornilov
---
drivers/tty/serial/8250/8250_port.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index 0bbf340..8ad0b2d 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1280,6 +1280,19 @@ static void autoconfig_irq(struct uart_8250_port *up)
port->irq = (irq > 0) ? irq : 0;
}
+static void serial8250_stop_rx(struct uart_port *port)
+{
+ struct uart_8250_port *up = up_to_u8250p(port);
+
+ serial8250_rpm_get(up);
+
+ up->ier &= ~(UART_IER_RLSI | UART_IER_RDI);
+ up->port.read_status_mask &= ~UART_LSR_DR;
+ serial_port_out(port, UART_IER, up->ier);
+
+ serial8250_rpm_put(up);
+}
+
static inline void __stop_tx(struct uart_8250_port *p)
{
if (p->ier & UART_IER_THRI) {
@@ -1347,19 +1360,6 @@ static void serial8250_unthrottle(struct uart_port *port)
port->unthrottle(port);
}
-static void serial8250_stop_rx(struct uart_port *port)
-{
- struct uart_8250_port *up = up_to_u8250p(port);
-
- serial8250_rpm_get(up);
-
- up->ier &= ~(UART_IER_RLSI | UART_IER_RDI);
- up->port.read_status_mask &= ~UART_LSR_DR;
- serial_port_out(port, UART_IER, up->ier);
-
- serial8250_rpm_put(up);
-}
-
static void serial8250_disable_ms(struct uart_port *port)
{
struct uart_8250_port *up =
--
2.6.3
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485
2015-11-18 21:33 GMT+03:00 Peter Hurley : > On 11/17/2015 03:20 AM, Matwey V. Kornilov wrote: >> 2015-11-16 22:18 GMT+03:00 Peter Hurley : >>> On 11/14/2015 10:25 AM, One Thousand Gnomes wrote: >>>>> I specifically asked for it. >>>>> >>>>> I can think of 2 reasons that userspace wants to know: >>>>> 1. Because the characteristics of the software emulation are unacceptable >>>>> so >>>>>the application wants to terminate w/error rather than continue. >>>> >>>> But that could equally be true of hardware. >>> >>> I had this exact same thought, but concluded that it argues for a way >>> to select the software implementation even when h/w supports RS485. >>> >>>> In fact your software >>>> emulation is going to behave vastly better than many of the hardware ones. >>>> >>>>> 2. Because userspace will use different values for h/w vs. s/w. For >>>>> example, >>>>>right now, the emulation will raise/lower RTS prematurely when tx ends >>>>> if >>>>>the rts-after-send timer is 0. >>>> >>>> That's a bug then. It should be fixed as part of the merge or future >>>> patches - if they are not providing that emulation then they ought to do >>>> so and at least adjust the timing based on the baud rate so you don't >>>> have to spin polling the 16x50 uart to check the last bit fell out of the >>>> register. >>> >>> I suppose the timer(s) could be fudged and then TEMT polled (or polled every >>> char baud cycles). But I don't see how this will behave better than a h/w >>> implementation; the granularity of the jiffy clock alone will guarantee >>> sub-optimal turnaround, even at 9600. >>> >>>> I'd have no problem with an API that was about asking what features are >>>> available : both hardware and software - but the software flag seems to >>>> make no sense at all. Software doesn't imply anything about quality or >>>> feature set. If there is something the emulation cannot support then >>>> there should be a flag indicating that feature is not supported, not a >>>> flag saying software (which means nothing - as it may be supported in >>>> future, or may differ by uart etc). >>> >>> Fair enough. >>> >>>> It's also not "easy to drop". If it ever goes in we are stuck with a >>>> pointless impossible to correctly set flag for all eternity. >>>> >>>> Please explain the correct setting for this flag when a device driver >>>> uses hardware or software or a mix according to what the silicon is >>>> capable of and what values are requested ? How will an application use the >>>> flag meaningfully. Please explain what will happen if someone discovers a >>>> silicon bug and in a future 4.x release turns an implementation from >>>> hardware to software - will they have to lie about the flag to avoid >>>> breaking their application code - that strikes me as a bad thing. >>> >>> The existing driver behavior is already significantly variant and needs >>> to be converged, which shouldn't be too difficult. Here's a quick summary: >>> >>> mcfuart ignores delay values, delays unsupported >>> imx clamps delay values to 0, delays unsupported >>> atmel only delay_rts_after_send used; delay_rts_before_send does >>> nothing >>> 8250_fintek clamps delay values to 1, unclear if h/w delay is msecs >>> omap-serial*software emulation (but tx empty polling not reqd) >>> lpc18xx-uartclamps delay_rts_before_send to 0, unsupported >>> clamps delay_rts_after_send to max h/w value >>> max310x returns -ERANGE if either delay value > h/w support (15 >>> msecs) >>> sc16is7xx* returns -EINVAL if delay_rts_after_send is set >>> crisv10*clamps delay_rts_before_send to 1000 msecs >>> ignores delays_rts_after_send (after dma is delayed by 2 * >>> chars) >>> * implements delay(s) in software >>> >>> The omap-serial emulation should not have been merged in its current form. >>> >>> IMO the proper driver behavior should be clamp to h/w limit so an >>> application >>> can determine the maximum delay supported. If a delay is unsupported, it >>>
Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485
2015-11-18 22:39 GMT+03:00 Matwey V. Kornilov : > 2015-11-18 21:33 GMT+03:00 Peter Hurley : >> On 11/17/2015 03:20 AM, Matwey V. Kornilov wrote: >>> 2015-11-16 22:18 GMT+03:00 Peter Hurley : >>>> On 11/14/2015 10:25 AM, One Thousand Gnomes wrote: >>>>>> I specifically asked for it. >>>>>> >>>>>> I can think of 2 reasons that userspace wants to know: >>>>>> 1. Because the characteristics of the software emulation are >>>>>> unacceptable so >>>>>>the application wants to terminate w/error rather than continue. >>>>> >>>>> But that could equally be true of hardware. >>>> >>>> I had this exact same thought, but concluded that it argues for a way >>>> to select the software implementation even when h/w supports RS485. >>>> >>>>> In fact your software >>>>> emulation is going to behave vastly better than many of the hardware ones. >>>>> >>>>>> 2. Because userspace will use different values for h/w vs. s/w. For >>>>>> example, >>>>>>right now, the emulation will raise/lower RTS prematurely when tx >>>>>> ends if >>>>>>the rts-after-send timer is 0. >>>>> >>>>> That's a bug then. It should be fixed as part of the merge or future >>>>> patches - if they are not providing that emulation then they ought to do >>>>> so and at least adjust the timing based on the baud rate so you don't >>>>> have to spin polling the 16x50 uart to check the last bit fell out of the >>>>> register. >>>> >>>> I suppose the timer(s) could be fudged and then TEMT polled (or polled >>>> every >>>> char baud cycles). But I don't see how this will behave better than a h/w >>>> implementation; the granularity of the jiffy clock alone will guarantee >>>> sub-optimal turnaround, even at 9600. >>>> >>>>> I'd have no problem with an API that was about asking what features are >>>>> available : both hardware and software - but the software flag seems to >>>>> make no sense at all. Software doesn't imply anything about quality or >>>>> feature set. If there is something the emulation cannot support then >>>>> there should be a flag indicating that feature is not supported, not a >>>>> flag saying software (which means nothing - as it may be supported in >>>>> future, or may differ by uart etc). >>>> >>>> Fair enough. >>>> >>>>> It's also not "easy to drop". If it ever goes in we are stuck with a >>>>> pointless impossible to correctly set flag for all eternity. >>>>> >>>>> Please explain the correct setting for this flag when a device driver >>>>> uses hardware or software or a mix according to what the silicon is >>>>> capable of and what values are requested ? How will an application use the >>>>> flag meaningfully. Please explain what will happen if someone discovers a >>>>> silicon bug and in a future 4.x release turns an implementation from >>>>> hardware to software - will they have to lie about the flag to avoid >>>>> breaking their application code - that strikes me as a bad thing. >>>> >>>> The existing driver behavior is already significantly variant and needs >>>> to be converged, which shouldn't be too difficult. Here's a quick summary: >>>> >>>> mcfuart ignores delay values, delays unsupported >>>> imx clamps delay values to 0, delays unsupported >>>> atmel only delay_rts_after_send used; delay_rts_before_send does >>>> nothing >>>> 8250_fintek clamps delay values to 1, unclear if h/w delay is msecs >>>> omap-serial*software emulation (but tx empty polling not reqd) >>>> lpc18xx-uartclamps delay_rts_before_send to 0, unsupported >>>> clamps delay_rts_after_send to max h/w value >>>> max310x returns -ERANGE if either delay value > h/w support (15 >>>> msecs) >>>> sc16is7xx* returns -EINVAL if delay_rts_after_send is set >>>> crisv10*clamps delay_rts_before_send to 1000 msecs >>>> ignores delays_rts_after_send (after dma is delayed by 2 * >>>> chars) >>&
Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485
2015-12-03 2:20 GMT+03:00 Peter Hurley : > On 11/18/2015 02:49 PM, Matwey V. Kornilov wrote: >> 2015-11-18 22:39 GMT+03:00 Matwey V. Kornilov : >>> 2015-11-18 21:33 GMT+03:00 Peter Hurley : >>>> On 11/17/2015 03:20 AM, Matwey V. Kornilov wrote: >>>>> 2015-11-16 22:18 GMT+03:00 Peter Hurley : >>>>>> On 11/14/2015 10:25 AM, One Thousand Gnomes wrote: > [...] >>>>>>> It's also not "easy to drop". If it ever goes in we are stuck with a >>>>>>> pointless impossible to correctly set flag for all eternity. >>>>>>> >>>>>>> Please explain the correct setting for this flag when a device driver >>>>>>> uses hardware or software or a mix according to what the silicon is >>>>>>> capable of and what values are requested ? How will an application use >>>>>>> the >>>>>>> flag meaningfully. Please explain what will happen if someone discovers >>>>>>> a >>>>>>> silicon bug and in a future 4.x release turns an implementation from >>>>>>> hardware to software - will they have to lie about the flag to avoid >>>>>>> breaking their application code - that strikes me as a bad thing. >>>>>> >>>>>> The existing driver behavior is already significantly variant and needs >>>>>> to be converged, which shouldn't be too difficult. Here's a quick >>>>>> summary: >>>>>> >>>>>> mcfuart ignores delay values, delays unsupported >>>>>> imx clamps delay values to 0, delays unsupported >>>>>> atmel only delay_rts_after_send used; delay_rts_before_send >>>>>> does nothing >>>>>> 8250_fintek clamps delay values to 1, unclear if h/w delay is msecs >>>>>> omap-serial*software emulation (but tx empty polling not reqd) >>>>>> lpc18xx-uartclamps delay_rts_before_send to 0, unsupported >>>>>> clamps delay_rts_after_send to max h/w value >>>>>> max310x returns -ERANGE if either delay value > h/w support (15 >>>>>> msecs) >>>>>> sc16is7xx* returns -EINVAL if delay_rts_after_send is set >>>>>> crisv10*clamps delay_rts_before_send to 1000 msecs >>>>>> ignores delays_rts_after_send (after dma is delayed by 2 >>>>>> * chars) >>>>>> * implements delay(s) in software >>>>>> >>>>>> The omap-serial emulation should not have been merged in its current >>>>>> form. >>>>>> >>>>>> IMO the proper driver behavior should be clamp to h/w limit so an >>>>>> application >>>>>> can determine the maximum delay supported. If a delay is unsupported, it >>>>>> should >>>>>> be clamped to 0. The application should check the RS485 settings >>>>>> returned by >>>>>> TIOCSRS485 to determine how the driver set them. >>>>>> [ Documentation/serial/serial-rs485.txt should suggest/model this action >>>>>> ] >>>>> >>>>> But the similar could be true for minimal supported delay. If user >>>>> requires delay which is less than lower bound, the delay is raised to >>>>> the lower bound. If user requires delay which is greater than upper >>>>> bound, the delay is set to the upper bound. Then software >>>>> implementation could use (tx fifo size / baudrate) as lower bound for >>>>> delay_after_send. >>>> >>>> From the application point-of-view (really the only relevant semantics), >>>> delay_dts_after_send refers to the number of milliseconds to delay the >>>> toggle of RTS after the last bit has been _transmitted_. > > Is there consensus then about what the semantics of unsupported RS485 delay > values are? I (or someone else) can trivially add the documentation and > fixes to the existing in-tree drivers. > > >>>> A couple of possibilities for improving the emulation are: >>>> 1) Optionally using an HR timer for sub-jiffy turnaround. >>>> 2) Only supporting 8250-based hardware that can be set to interrupt when >>>>both tx fifo and transmitter shift register are empty. >>> >>> This is to support the RS485 API wit
Re: [PATCH v3 2/5] tty: Introduce SER_RS485_SOFTWARE read-only flag for struct serial_rs485
2015-12-03 17:41 GMT+03:00 Peter Hurley : > Hi Matwey, > > On 12/03/2015 12:50 AM, Matwey V. Kornilov wrote: >> I am working on v4, where I completely redesigned implementation. And >> now I think that it is considerably better than v3. >> It looks like the following: >> https://github.com/matwey/linux/commits/8520_rs485_v4 >> But it is not ready yet, there is a bug somewhere. >> >> In the v4, each subdriver decides separately if it needs rs485 >> emulation support. Then it enables it like the following: >> https://github.com/matwey/linux/commit/4455e425fc045713fb921ccec695fe183f1558f0 >> Before calling serial8250_rs485_emul_enabled, the driver enables >> interrupt on empty shift register (they are always there for omap_). > > Looks good. > > Are you testing with CONFIG_SERIAL_8250_DMA=n first to simplify the > debug effort? DMA adds a completely different tx path. Many thanks for the advice. I've just found that the bug is not in my code =) Even with pure 4.3.0 I cannot open /dev/ttyS5 more than once. It just hangs on open() and the process is in S+ state. > > Also, before submission, please shorten the identifiers. And Greg hates > functions returning bool so just expanded serial8250_rs485_emul_enabled() > inline. Am I allowed to use `re' instead of rs485_emul in names? > > Regards, > Peter Hurley > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382 -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 3/3] tty: 8250_omap: Use software emulated RS485 direction control
2016-01-23 18:20 GMT+03:00 Andy Shevchenko :
> On Tue, Jan 19, 2016 at 10:33 PM, Matwey V. Kornilov
> wrote:
>> Use software emulated RS485 direction control to provide RS485 API existed in
>> omap_serial driver. Note that 8250_omap issues interrupt on shift register
>> empty which is single prerequesite for using software emulated RS485.
>
>
>> +static int omap_8250_rs485_config(struct uart_port *port, struct
>> serial_rs485 *rs485)
>> +{
>> + struct uart_8250_port *up = up_to_u8250p(port);
>> +
>> + /* Clamp the delays to [0, 100ms] */
>
> It's not exactly clamping but rather cutting extra as I can see below.
>
I took this code and the comment from
http://marc.info/?l=linux-serial&m=145264055108439&w=2
>> + rs485->delay_rts_before_send = min(rs485->delay_rts_before_send,
>> 100U);
>> + rs485->delay_rts_after_send = min(rs485->delay_rts_after_send,
>> 100U);
>
>> + /* Both serial8250_em485_* functions are idempotent */
>
> Better to decode what functions do you mean here.
>
>> + if (rs485->flags & SER_RS485_ENABLED) {
>> + int ret = serial8250_em485_init(up);
>> + if (ret) {
>> + rs485->flags &= ~SER_RS485_ENABLED;
>> + port->rs485.flags &= ~SER_RS485_ENABLED;
>> + }
>
>> + return ret;
>> + } else
>
> You have to do } else { in multi-line branches, but luckily there is
> redundant else keyword.
>
> And checkpatch.pl doesn't tell you anything?
>
>> + serial8250_em485_destroy(up);
>> +
>> + return 0;
>> +}
>
> --
> With Best Regards,
> Andy Shevchenko
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
[PATCH v1] tty: serial: Use GFP_ATOMIC instead of GFP_KERNEL in serial8250_em485_init()
serial8250_em485_init() is supposed to be protected with
p->port.lock spinlock.
This may lead to issues when kmalloc sleeps, so it is better to use
GFP_ATOMIC in this spinlocked context.
Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250")
Reported-by:
Signed-off-by: Matwey V. Kornilov
---
drivers/tty/serial/8250/8250_port.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index c908b77..4d6deef 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -586,7 +586,7 @@ int serial8250_em485_init(struct uart_8250_port *p)
if (p->em485 != NULL)
return 0;
- p->em485 = kmalloc(sizeof(struct uart_8250_em485), GFP_KERNEL);
+ p->em485 = kmalloc(sizeof(struct uart_8250_em485), GFP_ATOMIC);
if (p->em485 == NULL)
return -ENOMEM;
--
2.7.0
Re: [PATCH v1] tty: serial: Use GFP_ATOMIC instead of GFP_KERNEL in serial8250_em485_init()
2016-02-18 23:21 GMT+03:00 Andy Shevchenko :
> On Thu, Feb 18, 2016 at 8:47 PM, Matwey V. Kornilov wrote:
>> serial8250_em485_init() is supposed to be protected with
>> p->port.lock spinlock.
>> This may lead to issues when kmalloc sleeps, so it is better to use
>> GFP_ATOMIC in this spinlocked context.
>>
>> Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250")
>> Reported-by:
>
> Hmm... Can't we put Cyrillic characters to tags as name of a person?
I am afraid non-ASCII will break something eventually. I think it
would be better to ask Ilias to put his name in proper latin
transcription here.
> --
> With Best Regards,
> Andy Shevchenko
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
[PATCH v2] tty: serial: Use GFP_ATOMIC instead of GFP_KERNEL in serial8250_em485_init()
serial8250_em485_init() is supposed to be protected with
p->port.lock spinlock.
This may lead to issues when kmalloc sleeps, so it is better to use
GFP_ATOMIC in this spinlocked context.
Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250")
Reported-by: Ильяс Гасанов
Signed-off-by: Matwey V. Kornilov
---
Changes from v1:
- Properly filled Reported-by: tag
drivers/tty/serial/8250/8250_port.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index c908b77..4d6deef 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -586,7 +586,7 @@ int serial8250_em485_init(struct uart_8250_port *p)
if (p->em485 != NULL)
return 0;
- p->em485 = kmalloc(sizeof(struct uart_8250_em485), GFP_KERNEL);
+ p->em485 = kmalloc(sizeof(struct uart_8250_em485), GFP_ATOMIC);
if (p->em485 == NULL)
return -ENOMEM;
--
2.7.0
Re: [PATCH v1] tty: serial: Use GFP_ATOMIC instead of GFP_KERNEL in serial8250_em485_init()
2016-02-19 2:47 GMT+03:00 Greg Kroah-Hartman :
> On Thu, Feb 18, 2016 at 11:29:07PM +0300, Matwey V. Kornilov wrote:
>> 2016-02-18 23:21 GMT+03:00 Andy Shevchenko :
>> > On Thu, Feb 18, 2016 at 8:47 PM, Matwey V. Kornilov
>> > wrote:
>> >> serial8250_em485_init() is supposed to be protected with
>> >> p->port.lock spinlock.
>> >> This may lead to issues when kmalloc sleeps, so it is better to use
>> >> GFP_ATOMIC in this spinlocked context.
>> >>
>> >> Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250")
>> >> Reported-by:
>> >
>> > Hmm... Can't we put Cyrillic characters to tags as name of a person?
>>
>> I am afraid non-ASCII will break something eventually. I think it
>> would be better to ask Ilias to put his name in proper latin
>> transcription here.
>
> Why, we accept non-ASCII names all the time, why would we not do so?
>
> Please fix up and resend.
Sure, I've just sent v2.
I am used that non-ASCIIs break things, as they did it 20 years ago,
as they do it in 2016. GhostView stole all my Cyrillic characters from
PDF when I tried to embed fonts two days ago .
>
> thansk,
>
> greg k-h
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
Re: [PATCH v8 0/3] tty: Introduce software RS485 direction control support
2016-02-10 19:05 GMT+03:00 Peter Hurley : > Hi Matwey, > > On 02/01/2016 10:09 AM, Matwey V. Kornilov wrote: >> Changes from v7: >> - rework comments to follow guidelines >> - minor style changes >> Changes from v6: >> - minor style changes >> - timers are not IRQSAFE now >> Changes from v5: >> - rs485_emul variable has been renamed to em485 to follow function names >> convention >> Changes from v4: >> - Add commit message to 1/3 >> Changes from v3: >> - Completely redesigned. >> Changes from v2: >> - Introduced SER_RS485_SOFTWARE to show that software implementation is >> being used >> - serial8250_rs485_config is located as required >> - Timers are used to implement delay_before and delay_after timeouts >> >> Signed-off-by: Matwey V. Kornilov > > The holdup here is that I'd like to unit test this, which is 3rd on my todo > list. > Should be done before the end of the week which will be soon enough > for this series to make linux-next. Hi Peter, Is something required from me? > > Thanks for your work on this. > > Regards, > Peter Hurley > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
[PATCH v2 RESEND] tty: serial: Use GFP_ATOMIC instead of GFP_KERNEL in serial8250_em485_init()
serial8250_em485_init() is supposed to be protected with
p->port.lock spinlock.
This may lead to issues when kmalloc sleeps, so it is better to use
GFP_ATOMIC in this spinlocked context.
Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250")
Reported-by: Ильяс Гасанов
Signed-off-by: Matwey V. Kornilov
---
Changes from v1:
- Properly filled Reported-by: tag
drivers/tty/serial/8250/8250_port.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index c908b77..4d6deef 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -586,7 +586,7 @@ int serial8250_em485_init(struct uart_8250_port *p)
if (p->em485 != NULL)
return 0;
- p->em485 = kmalloc(sizeof(struct uart_8250_em485), GFP_KERNEL);
+ p->em485 = kmalloc(sizeof(struct uart_8250_em485), GFP_ATOMIC);
if (p->em485 == NULL)
return -ENOMEM;
--
2.7.0
[PATCH v1] tty: serial: 8250: Cleanup p->em485 in serial8250_unregister_port
Formally, currently there is no memory leak, but if
serial8250_ports[line] is reused with other 8250 driver, then em485
will be already activated and it will cause issues.
Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250")
Signed-off-by: Matwey V. Kornilov
---
Hi Peter,
There is an issue with my previous patch. Under specific circumstances,
the emulation can be enabled for drivers which don't want (and support) it.
Unfortunately, I can't test this patch because kgdb over 8250_omap console
is the single one option for me on BBB. This patch testing involves
8250_omap module unloading and then inspecting serial8250_ports.
You say that you are preparing some unit-tests. Could you include a test
for this specific issue? And then probably this patch has to be applied.
drivers/tty/serial/8250/8250_core.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index c9720a9..a242881 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1068,6 +1068,15 @@ void serial8250_unregister_port(int line)
struct uart_8250_port *uart = &serial8250_ports[line];
mutex_lock(&serial_mutex);
+
+ if (uart->em485) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&uart->port.lock, flags);
+ serial8250_em485_destroy(uart);
+ spin_unlock_irqrestore(&uart->port.lock, flags);
+ }
+
uart_remove_one_port(&serial8250_reg, &uart->port);
if (serial8250_isa_devs) {
uart->port.flags &= ~UPF_BOOT_AUTOCONF;
--
2.7.0
Re: [RFC PATCH] dts: Add am335x-wega-rdk.dtb sources for phyBOARD-Wega-AM335x
Hi,
Teresa replied me, but unfortunately I found that the answer not
reached the public maillists. Briefly, we don't need this patch,
PhyTec will send better one this year.
2015-03-07 15:59 GMT+03:00 Matwey V. Kornilov :
> The following patch is to support Phytec phyBOARD-Wega-AM335x device.
> The patch consists of the commits taken from
>
> git://git.phytec.de/linux-ti
>
> and ported to upstream kernel with small modifications,
> i.e. &ctrl_mod renamed to &usb_ctrl_mod.
>
> The code has been written by the following developers:
> Christian Arlt
> Stefan Müller-Klieser
> Teresa Gámez
> Wadim Egorov
>
> Tested-by: Matwey V. Kornilov
> Signed-off-by: Matwey V. Kornilov
> ---
> The patch has been tested on 3.19.0 with openSUSE Factory on
> phyBOARD-Wega-AM335x kit. The board successfully boots, ethernet works.
>
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/am335x-phycore-som.dtsi | 275
> +
> arch/arm/boot/dts/am335x-phytec-lcd-018.dtsi | 109 ++
> arch/arm/boot/dts/am335x-wega-peb-av-01.dtsi | 71 +++
> arch/arm/boot/dts/am335x-wega-peb-av-02.dtsi | 44
> arch/arm/boot/dts/am335x-wega-peb-eval-01.dtsi | 54 +
> arch/arm/boot/dts/am335x-wega-rdk.dts | 136
> arch/arm/boot/dts/am335x-wega.dtsi | 209 +++
> 8 files changed, 900 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
> create mode 100644 arch/arm/boot/dts/am335x-phytec-lcd-018.dtsi
> create mode 100644 arch/arm/boot/dts/am335x-wega-peb-av-01.dtsi
> create mode 100644 arch/arm/boot/dts/am335x-wega-peb-av-02.dtsi
> create mode 100644 arch/arm/boot/dts/am335x-wega-peb-eval-01.dtsi
> create mode 100644 arch/arm/boot/dts/am335x-wega-rdk.dts
> create mode 100644 arch/arm/boot/dts/am335x-wega.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a1c776b..aa05ae4 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -401,7 +401,8 @@ dtb-$(CONFIG_SOC_AM33XX) += \
> am335x-evmsk.dtb \
> am335x-nano.dtb \
> am335x-pepper.dtb \
> - am335x-lxm.dtb
> + am335x-lxm.dtb \
> + am335x-wega-rdk.dts
> dtb-$(CONFIG_ARCH_OMAP4) += \
> omap4-duovero-parlor.dtb \
> omap4-panda.dtb \
> diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
> b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> new file mode 100644
> index 000..aa7826d
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> @@ -0,0 +1,275 @@
> +/*
> + * Copyright (C) 2014 Teresa Gámez Phytec Messtechnik
> GmbH
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "am33xx.dtsi"
> +
> +/ {
> + model = "Phytec AM335x phyCORE";
> + compatible = "phytec,am335x-phycore-som", "ti,am33xx";
> +
> + aliases {
> + rtc0 = &i2c_rtc;
> + rtc1 = &rtc;
> + };
> +
> + cpus {
> + cpu@0 {
> + cpu0-supply = <&vdd1_reg>;
> + };
> + };
> +
> + /* This is a dummy node. Will be set by a bootloader */
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512 MB */
> + };
> +
> + vcc5v: fixedregulator@0 {
> + compatible = "regulator-fixed";
> + };
> +};
> +
> +/* Crypto Module */
> +&aes {
> + status = "okay";
> +};
> +
> +&sham {
> + status = "okay";
> +};
> +
> +/* Ethernet */
> +&am33xx_pinmux {
> + ethernet0_pins: pinmux_ethernet0 {
> + pinctrl-single,pins = <
> + 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_crs.rmii1_crs_dv */
> + 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_rxerr.rmii1_rxerr */
> + 0x114 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txen.rmii1_txen */
> + 0x124 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txd1.rmii1_txd1 */
> + 0x128 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txd0.rmii1_txd0 */
> + 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_rxd1.rmii1_rxd1 */
> +
Re: [PATCH v3] pci: spear: Drop __initdata from spear13xx_pcie_driver
2015-03-06 17:42 GMT+03:00 Stanimir Varbanov : > On 02/19/2015 07:41 PM, Matwey V. Kornilov wrote: >> spear13xx_pcie_driver.driver is allocated in text.init section >> and then the pointer to it is passed futher. This patch is to avoid >> crashes like the following, when freed memory is used. >> > > What happened with this patch, could it go as a fix? > With this patch the kernel works as expected (without crashes), I think it could be considered as a fix. -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] dts: Add am335x-wega-rdk.dtb sources for phyBOARD-Wega-AM335x
The following patch is to support Phytec phyBOARD-Wega-AM335x device.
The patch consists of the commits taken from
git://git.phytec.de/linux-ti
and ported to upstream kernel with small modifications,
i.e. &ctrl_mod renamed to &usb_ctrl_mod.
The code has been written by the following developers:
Christian Arlt
Stefan Müller-Klieser
Teresa Gámez
Wadim Egorov
Tested-by: Matwey V. Kornilov
Signed-off-by: Matwey V. Kornilov
---
The patch has been tested on 3.19.0 with openSUSE Factory on
phyBOARD-Wega-AM335x kit. The board successfully boots, ethernet works.
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/am335x-phycore-som.dtsi | 275 +
arch/arm/boot/dts/am335x-phytec-lcd-018.dtsi | 109 ++
arch/arm/boot/dts/am335x-wega-peb-av-01.dtsi | 71 +++
arch/arm/boot/dts/am335x-wega-peb-av-02.dtsi | 44
arch/arm/boot/dts/am335x-wega-peb-eval-01.dtsi | 54 +
arch/arm/boot/dts/am335x-wega-rdk.dts | 136
arch/arm/boot/dts/am335x-wega.dtsi | 209 +++
8 files changed, 900 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
create mode 100644 arch/arm/boot/dts/am335x-phytec-lcd-018.dtsi
create mode 100644 arch/arm/boot/dts/am335x-wega-peb-av-01.dtsi
create mode 100644 arch/arm/boot/dts/am335x-wega-peb-av-02.dtsi
create mode 100644 arch/arm/boot/dts/am335x-wega-peb-eval-01.dtsi
create mode 100644 arch/arm/boot/dts/am335x-wega-rdk.dts
create mode 100644 arch/arm/boot/dts/am335x-wega.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a1c776b..aa05ae4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -401,7 +401,8 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-evmsk.dtb \
am335x-nano.dtb \
am335x-pepper.dtb \
- am335x-lxm.dtb
+ am335x-lxm.dtb \
+ am335x-wega-rdk.dts
dtb-$(CONFIG_ARCH_OMAP4) += \
omap4-duovero-parlor.dtb \
omap4-panda.dtb \
diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
b/arch/arm/boot/dts/am335x-phycore-som.dtsi
new file mode 100644
index 000..aa7826d
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -0,0 +1,275 @@
+/*
+ * Copyright (C) 2014 Teresa Gámez Phytec Messtechnik GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "am33xx.dtsi"
+
+/ {
+ model = "Phytec AM335x phyCORE";
+ compatible = "phytec,am335x-phycore-som", "ti,am33xx";
+
+ aliases {
+ rtc0 = &i2c_rtc;
+ rtc1 = &rtc;
+ };
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&vdd1_reg>;
+ };
+ };
+
+ /* This is a dummy node. Will be set by a bootloader */
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x2000>; /* 512 MB */
+ };
+
+ vcc5v: fixedregulator@0 {
+ compatible = "regulator-fixed";
+ };
+};
+
+/* Crypto Module */
+&aes {
+ status = "okay";
+};
+
+&sham {
+ status = "okay";
+};
+
+/* Ethernet */
+&am33xx_pinmux {
+ ethernet0_pins: pinmux_ethernet0 {
+ pinctrl-single,pins = <
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_crs.rmii1_crs_dv */
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxerr.rmii1_rxerr */
+ 0x114 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txen.rmii1_txen */
+ 0x124 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txd1.rmii1_txd1 */
+ 0x128 (PIN_OUTPUT | MUX_MODE1) /*
mii1_txd0.rmii1_txd0 */
+ 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxd1.rmii1_rxd1 */
+ 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
mii1_rxd0.rmii1_rxd0 */
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
rmii1_refclk.rmii1_refclk */
+ >;
+ };
+
+ mdio_pins: pinmux_mdio {
+ pinctrl-single,pins = <
+ /* MDIO */
+ 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
/* mdio_data.mdio_data */
+ 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+ >;
+ };
+};
+
+&cpsw_emac0 {
+ phy_id = <&davinci_mdio>, <0>;
+ phy-mode = "rmii";
+ dual_emac_res_vlan = <1>;
+ status = "disabled";
+};
+
+&cpsw_emac1 {
+ status = "disabled";
+};
+
+&davinci_mdio {
+ pinctrl-name
[PATCH] pci: spear: Drop __initdata from struct platform_driver spear13xx_pcie_driver
spear13xx_pcie_driver.driver is allocated in text.init section
and then the pointer to it is passed futher. This patch is to avoid
crashes like the following, when freed memory is used:
#0 __device_attach (drv=0xc0ed5608 ,
data=0xdb622610) at ../drivers/base/dd.c:409
#1 0xc07a4798 in bus_for_each_drv (bus=, start=, data=0xda0, fn=0xc07a6740 <__device_attach>)
at ../drivers/base/bus.c:463
#2 0xc07a6324 in device_attach (dev=0xdb622610) at ../drivers/base/dd.c:447
#3 0xc07a5814 in bus_probe_device (dev=0xdb622610) at
../drivers/base/bus.c:558
#4 0xc07a38d8 in device_add (dev=) at
../drivers/base/core.c:1058
#5 0xc08b6a5c in of_device_add (ofdev=) at
../drivers/of/device.c:66
#6 0xc08b742c in of_platform_device_create_pdata (np=,
bus_id=0x0 <__vectors_start>, platform_data=0x0 <__vectors_start>,
parent=) at ../drivers/of/platform.c:241
#7 0xc08b7568 in of_platform_bus_create (bus=0xdfa46780, matches=0x0
<__vectors_start>, lookup=0x0 <__vectors_start>, parent=0xdb183410,
strict=true) at ../drivers/of/platform.c:414
#8 0xc08b79bc in of_platform_populate (root=0xc0ed5608
, matches=0xdb622610, lookup=0xda0,
parent=0xc07a6740 <__device_attach>) at ../drivers/of/platform.c:501
#9 0xbf30 in am335x_child_probe (pdev=0xdb183400) at
../drivers/usb/musb/musb_am335x.c:12
#10 0xc07a83f0 in platform_drv_probe (_dev=0xdb183410) at
../drivers/base/platform.c:512
#11 0xc07a64e8 in really_probe (drv=, dev=) at
../drivers/base/dd.c:302
#12 driver_probe_device (drv=0xbf000234, dev=0xdb183410) at
../drivers/base/dd.c:399
#13 0xc07a6820 in __driver_attach (dev=0xdb183410, data=0xbf000234) at
../drivers/base/dd.c:477
#14 0xc07a46e8 in bus_for_each_dev (bus=, start=, data=0xda0, fn=0xc07a83a4 )
at ../drivers/base/bus.c:313
#15 0xc07a5ebc in driver_attach (drv=) at
../drivers/base/dd.c:496
#16 0xc07a5af0 in bus_add_driver (drv=0xbf000234) at ../drivers/base/bus.c:694
#17 0xc07a6fec in driver_register (drv=0xbf000234) at
../drivers/base/driver.c:167
#18 0xc0209c34 in do_one_initcall (fn=0xbf002000) at ../init/main.c:801
#19 0xc02e0494 in do_init_module (mod=) at
../kernel/module.c:3142
#20 load_module (info=0xdb6b1f54, uargs=, flags=) at ../kernel/module.c:3461
#21 0xc02e0a44 in SYSC_finit_module (flags=, uargs=, fd=) at ../kernel/module.c:3537
#22 SyS_finit_module (fd=7, uargs=-1225602132, flags=0) at
../kernel/module.c:3518
#23 0xc021a680 in ?? ()
Fixes: 6675ef212da (PCI: spear: Fix Section mismatch compilation warning for
probe())
Signed-off-by: Matwey V. Kornilov
---
drivers/pci/host/pcie-spear13xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pcie-spear13xx.c
b/drivers/pci/host/pcie-spear13xx.c
index 866465f..435651d 100644
--- a/drivers/pci/host/pcie-spear13xx.c
+++ b/drivers/pci/host/pcie-spear13xx.c
@@ -370,7 +370,7 @@ static const struct of_device_id spear13xx_pcie_of_match[]
= {
};
MODULE_DEVICE_TABLE(of, spear13xx_pcie_of_match);
-static struct platform_driver spear13xx_pcie_driver __initdata = {
+static struct platform_driver spear13xx_pcie_driver = {
.probe = spear13xx_pcie_probe,
.driver = {
.name = "spear-pcie",
--
2.1.4
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pci: spear: Drop __initdata from struct platform_driver spear13xx_pcie_driver
2015-02-09 7:22 GMT+03:00 Viresh Kumar : > On Sun, Feb 8, 2015 at 3:37 PM, Matwey V. Kornilov wrote: >> spear13xx_pcie_driver.driver is allocated in text.init section >> and then the pointer to it is passed futher. This patch is to avoid >> crashes like the following, when freed memory is used: >> >> #0 __device_attach (drv=0xc0ed5608 , >> data=0xdb622610) at ../drivers/base/dd.c:409 >> #1 0xc07a4798 in bus_for_each_drv (bus=, start=> out>, data=0xda0, fn=0xc07a6740 <__device_attach>) >> at ../drivers/base/bus.c:463 >> #2 0xc07a6324 in device_attach (dev=0xdb622610) at ../drivers/base/dd.c:447 >> #3 0xc07a5814 in bus_probe_device (dev=0xdb622610) at >> ../drivers/base/bus.c:558 >> #4 0xc07a38d8 in device_add (dev=) at >> ../drivers/base/core.c:1058 >> #5 0xc08b6a5c in of_device_add (ofdev=) at >> ../drivers/of/device.c:66 >> #6 0xc08b742c in of_platform_device_create_pdata (np=, >> bus_id=0x0 <__vectors_start>, platform_data=0x0 <__vectors_start>, >> parent=) at ../drivers/of/platform.c:241 >> #7 0xc08b7568 in of_platform_bus_create (bus=0xdfa46780, matches=0x0 >> <__vectors_start>, lookup=0x0 <__vectors_start>, parent=0xdb183410, >> strict=true) at ../drivers/of/platform.c:414 >> #8 0xc08b79bc in of_platform_populate (root=0xc0ed5608 >> , matches=0xdb622610, lookup=0xda0, >> parent=0xc07a6740 <__device_attach>) at ../drivers/of/platform.c:501 >> #9 0xbf30 in am335x_child_probe (pdev=0xdb183400) at >> ../drivers/usb/musb/musb_am335x.c:12 >> #10 0xc07a83f0 in platform_drv_probe (_dev=0xdb183410) at >> ../drivers/base/platform.c:512 >> #11 0xc07a64e8 in really_probe (drv=, dev=) >> at ../drivers/base/dd.c:302 >> #12 driver_probe_device (drv=0xbf000234, dev=0xdb183410) at >> ../drivers/base/dd.c:399 >> #13 0xc07a6820 in __driver_attach (dev=0xdb183410, data=0xbf000234) at >> ../drivers/base/dd.c:477 >> #14 0xc07a46e8 in bus_for_each_dev (bus=, start=> out>, data=0xda0, fn=0xc07a83a4 ) >> at ../drivers/base/bus.c:313 >> #15 0xc07a5ebc in driver_attach (drv=) at >> ../drivers/base/dd.c:496 >> #16 0xc07a5af0 in bus_add_driver (drv=0xbf000234) at >> ../drivers/base/bus.c:694 >> #17 0xc07a6fec in driver_register (drv=0xbf000234) at >> ../drivers/base/driver.c:167 >> #18 0xc0209c34 in do_one_initcall (fn=0xbf002000) at ../init/main.c:801 >> #19 0xc02e0494 in do_init_module (mod=) at >> ../kernel/module.c:3142 >> #20 load_module (info=0xdb6b1f54, uargs=, flags=> out>) at ../kernel/module.c:3461 >> #21 0xc02e0a44 in SYSC_finit_module (flags=, >> uargs=, fd=) at ../kernel/module.c:3537 >> #22 SyS_finit_module (fd=7, uargs=-1225602132, flags=0) at >> ../kernel/module.c:3518 >> #23 0xc021a680 in ?? () >> >> Fixes: 6675ef212da (PCI: spear: Fix Section mismatch compilation warning for >> probe()) > > wouldn't this again result in the problem reported above ? > Frankly speaking, I don't believe that that problem ever existed. probe() is marked as __init, it assumes that there are/were guarantees that nobody will require actual probing after the driver init. This way there is completely no difference where .probe points to. If one wants just to make linker happy and not see warnings, almost all __init specifications should be dropped out. -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia -- 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/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
