Re: [PATCH/RFC 0/4] Probe deferral for IOMMU DT integration
Hello, On 2015-02-07 23:41, a...@arndb.de wrote: Laura Abbott hat am 6. Februar 2015 um 01:31 geschrieben: The requirement for this is based on a previous patch to add clock support to the ARM SMMU driver[2]. Once we have clock support, it's possible that the driver itself may need to be defered which breaks a bunch of assumptions about how SMMU probing is supposed to work. Hi Laura, I was hoping that we would not need this, and instead treat the iommu in the same way as timers and SMP initialization, both of which need to be run early at boot time but may rely on clock controllers to be initialized first. Is there a specific requirement that makes this impossible here, or is your intention to solve the problem more nicely by allowing deferred probing over forcing the input clocks of the iommu to be early? I case of Exynos SoCs there is also a dependency on power domains (some might be disabled by the bootloader). It is convenient to use the whole device infrastructure for this although it still doesn't provide any methods of modelling the real power management dependencies. Right now I simply ignored this problem and left it for the future. I will check if this patchset helps in our case. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland -- 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 2/6] staging: rtl8188eu: hal: removed code indent error
On Wed, 2015-02-11 at 11:33 +0300, Dan Carpenter wrote: > On Tue, Feb 10, 2015 at 03:27:11PM +0100, Bas Peters wrote: > > >> @@ -101,8 +101,7 @@ void rtl88eu_phy_rf6052_set_cck_txpower(struct > > >> adapter *adapt, u8 *powerlevel) > > >> ptr++; > > >> } > > >> } > > >> - rtl88eu_dm_txpower_track_adjust(_data->odmpriv, 1, , > > >> - _value); > > >> + rtl88eu_dm_txpower_track_adjust(_data->odmpriv, 1, , > > >> _value); > > > you are introducing one warning to fix one error. line over 80 character. > > > > Isn't that warning more of a guideline, rather than an actual warning? Yes, it is more informational than defect. > You can't fight checkpatch.pl. Sure you can, Ignore it whenever appropriate. It's a pity there are _so_ many people that think checkpatch messages are gospel. > We reject the worst or the worst "break > lines up into smaller chunks" patches where they obviously hurt > readability, but we almost always silence the warning in the end. The > original code in this case was fine. Any line with 30+ char identifiers generally doesn't fit well in 80 char lines. -- 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] lpfc: Use setup_timer
This patch introduces the use of function setup_timer. This is done using Coccinelle and semantic patch used is as follows: @@ expression x,y,z; @@ - init_timer (); + setup_timer (, y, z); - x.function = y; - x.data = z; Signed-off-by: Vaishali Thakkar --- drivers/scsi/lpfc/lpfc_init.c | 67 ++- 1 file changed, 22 insertions(+), 45 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 0b2c53a..ca338ad 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -3287,21 +3287,16 @@ lpfc_create_port(struct lpfc_hba *phba, int instance, struct device *dev) INIT_LIST_HEAD(>rcv_buffer_list); spin_lock_init(>work_port_lock); - init_timer(>fc_disctmo); - vport->fc_disctmo.function = lpfc_disc_timeout; - vport->fc_disctmo.data = (unsigned long)vport; + setup_timer(>fc_disctmo, lpfc_disc_timeout, + (unsigned long)vport); - init_timer(>fc_fdmitmo); - vport->fc_fdmitmo.function = lpfc_fdmi_tmo; - vport->fc_fdmitmo.data = (unsigned long)vport; + setup_timer(>fc_fdmitmo, lpfc_fdmi_tmo, (unsigned long)vport); - init_timer(>els_tmofunc); - vport->els_tmofunc.function = lpfc_els_timeout; - vport->els_tmofunc.data = (unsigned long)vport; + setup_timer(>els_tmofunc, lpfc_els_timeout, + (unsigned long)vport); - init_timer(>delayed_disc_tmo); - vport->delayed_disc_tmo.function = lpfc_delayed_disc_tmo; - vport->delayed_disc_tmo.data = (unsigned long)vport; + setup_timer(>delayed_disc_tmo, lpfc_delayed_disc_tmo, + (unsigned long)vport); error = scsi_add_host_with_dma(shost, dev, >pcidev->dev); if (error) @@ -4832,27 +4827,19 @@ lpfc_sli_driver_resource_setup(struct lpfc_hba *phba) */ /* Heartbeat timer */ - init_timer(>hb_tmofunc); - phba->hb_tmofunc.function = lpfc_hb_timeout; - phba->hb_tmofunc.data = (unsigned long)phba; + setup_timer(>hb_tmofunc, lpfc_hb_timeout, (unsigned long)phba); psli = >sli; /* MBOX heartbeat timer */ - init_timer(>mbox_tmo); - psli->mbox_tmo.function = lpfc_mbox_timeout; - psli->mbox_tmo.data = (unsigned long) phba; + setup_timer(>mbox_tmo, lpfc_mbox_timeout, (unsigned long)phba); /* FCP polling mode timer */ - init_timer(>fcp_poll_timer); - phba->fcp_poll_timer.function = lpfc_poll_timeout; - phba->fcp_poll_timer.data = (unsigned long) phba; + setup_timer(>fcp_poll_timer, lpfc_poll_timeout, + (unsigned long)phba); /* Fabric block timer */ - init_timer(>fabric_block_timer); - phba->fabric_block_timer.function = lpfc_fabric_block_timeout; - phba->fabric_block_timer.data = (unsigned long) phba; + setup_timer(>fabric_block_timer, lpfc_fabric_block_timeout, + (unsigned long)phba); /* EA polling mode timer */ - init_timer(>eratt_poll); - phba->eratt_poll.function = lpfc_poll_eratt; - phba->eratt_poll.data = (unsigned long) phba; + setup_timer(>eratt_poll, lpfc_poll_eratt, (unsigned long)phba); /* Host attention work mask setup */ phba->work_ha_mask = (HA_ERATT | HA_MBATT | HA_LATT); @@ -5008,30 +4995,20 @@ lpfc_sli4_driver_resource_setup(struct lpfc_hba *phba) */ /* Heartbeat timer */ - init_timer(>hb_tmofunc); - phba->hb_tmofunc.function = lpfc_hb_timeout; - phba->hb_tmofunc.data = (unsigned long)phba; - init_timer(>rrq_tmr); - phba->rrq_tmr.function = lpfc_rrq_timeout; - phba->rrq_tmr.data = (unsigned long)phba; + setup_timer(>hb_tmofunc, lpfc_hb_timeout, (unsigned long)phba); + setup_timer(>rrq_tmr, lpfc_rrq_timeout, (unsigned long)phba); psli = >sli; /* MBOX heartbeat timer */ - init_timer(>mbox_tmo); - psli->mbox_tmo.function = lpfc_mbox_timeout; - psli->mbox_tmo.data = (unsigned long) phba; + setup_timer(>mbox_tmo, lpfc_mbox_timeout, (unsigned long)phba); /* Fabric block timer */ - init_timer(>fabric_block_timer); - phba->fabric_block_timer.function = lpfc_fabric_block_timeout; - phba->fabric_block_timer.data = (unsigned long) phba; + setup_timer(>fabric_block_timer, lpfc_fabric_block_timeout, + (unsigned long)phba); /* EA polling mode timer */ - init_timer(>eratt_poll); - phba->eratt_poll.function = lpfc_poll_eratt; - phba->eratt_poll.data = (unsigned long) phba; + setup_timer(>eratt_poll, lpfc_poll_eratt, (unsigned long)phba); /* FCF rediscover timer */ - init_timer(>fcf.redisc_wait); - phba->fcf.redisc_wait.function = lpfc_sli4_fcf_redisc_wait_tmo; - phba->fcf.redisc_wait.data = (unsigned long)phba; + setup_timer(>fcf.redisc_wait,
Re: Recommendations for a new MFD device driver?
On Tue, Feb 10, 2015 at 03:20:39PM +0800, Lee Jones wrote: > On Fri, 06 Feb 2015, Sascha Hauer wrote: > > > Hi All, > > > > We are adding support for a new pretty typical MFD device, the MediaTek > > MT6397. Initial patches are already posted. It's a PMIC which among other > > things has regulators and a RTC. The same RTC is reused on another PMIC, > > but with another register offset and another interrupt. > > > > Now the question is where shall we put the register/irq resource > > information? > > > > 1) Put it into the RTC device driver. > > 2) Put it into the .resource field of struct mfd_cell > > 3) Put it into the device tree using standard reg, interrupt properties and > >a) Let the RTC driver interpret these > >b) Let the MFD driver create resources in the .resource field of struct > > mfd_cell > >c) Let the MFD core create the resources > > I have no problem with 2, if that's the route you'd like to take. Ok, thanks Lee and Mark for the input. I think we should go with option 2 then. While it's convenient to put the resources into the device tree in the first place, it probably becomes cumbersome when Linux gets a different idea how the subdevices of the PMIC should be arranged. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 5/6] ALSA: line6: Use explicit type for serial number
At Tue, 10 Feb 2015 23:03:16 -0600,
Chris Rorvick wrote:
>
> The serial number (aka ESN) is a 32-bit value.
>
> Signed-off-by: Chris Rorvick
Applied, thanks.
Takashi
> ---
> sound/usb/line6/driver.c | 2 +-
> sound/usb/line6/driver.h | 2 +-
> sound/usb/line6/pod.c | 4 ++--
> sound/usb/line6/toneport.c | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
> index f8e2eb0..d31ceb8 100644
> --- a/sound/usb/line6/driver.c
> +++ b/sound/usb/line6/driver.c
> @@ -426,7 +426,7 @@ EXPORT_SYMBOL_GPL(line6_write_data);
> Read Line 6 device serial number.
> (POD, TonePort, GuitarPort)
> */
> -int line6_read_serial_number(struct usb_line6 *line6, int *serial_number)
> +int line6_read_serial_number(struct usb_line6 *line6, u32 *serial_number)
> {
> return line6_read_data(line6, 0x80d0, serial_number,
> sizeof(*serial_number));
> diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
> index 603bdc4..b281bff 100644
> --- a/sound/usb/line6/driver.h
> +++ b/sound/usb/line6/driver.h
> @@ -150,7 +150,7 @@ extern char *line6_alloc_sysex_buffer(struct usb_line6
> *line6, int code1,
> extern int line6_read_data(struct usb_line6 *line6, u16 address, void *data,
> u8 datalen);
> extern int line6_read_serial_number(struct usb_line6 *line6,
> - int *serial_number);
> + u32 *serial_number);
> extern int line6_send_raw_message_async(struct usb_line6 *line6,
> const char *buffer, int size);
> extern int line6_send_sysex_message(struct usb_line6 *line6,
> diff --git a/sound/usb/line6/pod.c b/sound/usb/line6/pod.c
> index c4246ad..425d22d 100644
> --- a/sound/usb/line6/pod.c
> +++ b/sound/usb/line6/pod.c
> @@ -73,7 +73,7 @@ struct usb_line6_pod {
> int startup_progress;
>
> /* Serial number of device */
> - int serial_number;
> + u32 serial_number;
>
> /* Firmware version (x 100) */
> int firmware_version;
> @@ -247,7 +247,7 @@ static ssize_t serial_number_show(struct device *dev,
> struct usb_interface *interface = to_usb_interface(dev);
> struct usb_line6_pod *pod = usb_get_intfdata(interface);
>
> - return sprintf(buf, "%d\n", pod->serial_number);
> + return sprintf(buf, "%u\n", pod->serial_number);
> }
>
> /*
> diff --git a/sound/usb/line6/toneport.c b/sound/usb/line6/toneport.c
> index 1a0a485..ddf7368 100644
> --- a/sound/usb/line6/toneport.c
> +++ b/sound/usb/line6/toneport.c
> @@ -49,7 +49,7 @@ struct usb_line6_toneport {
> int source;
>
> /* Serial number of device */
> - int serial_number;
> + u32 serial_number;
>
> /* Firmware version (x 100) */
> int firmware_version;
> --
> 2.1.0
>
--
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 6/6] ALSA: line6: toneport: Use explicit type for firmware version
At Tue, 10 Feb 2015 23:03:17 -0600,
Chris Rorvick wrote:
>
> The firmware version is a single byte so have the variable type agree.
> Since the address to this member is passed to the read function, using
> an int is not even portable.
>
> Signed-off-by: Chris Rorvick
Applied, thanks.
Takashi
> ---
> sound/usb/line6/toneport.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/usb/line6/toneport.c b/sound/usb/line6/toneport.c
> index ddf7368..6d4c50c 100644
> --- a/sound/usb/line6/toneport.c
> +++ b/sound/usb/line6/toneport.c
> @@ -52,7 +52,7 @@ struct usb_line6_toneport {
> u32 serial_number;
>
> /* Firmware version (x 100) */
> - int firmware_version;
> + u8 firmware_version;
>
> /* Timer for delayed PCM startup */
> struct timer_list timer;
> --
> 2.1.0
>
--
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 4/6] ALSA: line6: Return EIO if read/write not successful
At Tue, 10 Feb 2015 23:03:15 -0600,
Chris Rorvick wrote:
>
> Signed-off-by: Chris Rorvick
Applied, thanks.
Takashi
> ---
> sound/usb/line6/driver.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
> index 2a33f3e..f8e2eb0 100644
> --- a/sound/usb/line6/driver.c
> +++ b/sound/usb/line6/driver.c
> @@ -349,7 +349,7 @@ int line6_read_data(struct usb_line6 *line6, u16 address,
> void *data,
> dev_err(line6->ifcdev,
> "length mismatch (expected %d, got %d)\n",
> (int)datalen, (int)len);
> - return -EINVAL;
> + return -EIO;
> }
>
> /* receive the result: */
> @@ -415,7 +415,7 @@ int line6_write_data(struct usb_line6 *line6, u16
> address, void *data,
> return -EIO;
> } else if (status != 0) {
> dev_err(line6->ifcdev, "write failed (error %d)\n", ret);
> - return -EINVAL;
> + return -EIO;
> }
>
> return 0;
> --
> 2.1.0
>
--
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 3/6] ALSA: line6: Return error if device not responding
At Tue, 10 Feb 2015 23:03:14 -0600,
Chris Rorvick wrote:
>
> Put an upper bound on how long we will wait for the device to respond to
> a read/write request (i.e., 100 milliseconds) and return an error if
> this is reached.
>
> Signed-off-by: Chris Rorvick
Applied, thanks.
Takashi
> ---
> sound/usb/line6/driver.c | 29 +++--
> 1 file changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
> index 222c14f..2a33f3e 100644
> --- a/sound/usb/line6/driver.c
> +++ b/sound/usb/line6/driver.c
> @@ -297,6 +297,7 @@ static void line6_data_received(struct urb *urb)
> }
>
> #define LINE6_READ_WRITE_STATUS_DELAY 2 /* milliseconds */
> +#define LINE6_READ_WRITE_MAX_RETRIES 50
>
> /*
> Read data from device.
> @@ -307,6 +308,7 @@ int line6_read_data(struct usb_line6 *line6, u16 address,
> void *data,
> struct usb_device *usbdev = line6->usbdev;
> int ret;
> unsigned char len;
> + unsigned count;
>
> /* query the serial number: */
> ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), 0x67,
> @@ -320,7 +322,7 @@ int line6_read_data(struct usb_line6 *line6, u16 address,
> void *data,
> }
>
> /* Wait for data length. We'll get 0xff until length arrives. */
> - do {
> + for (count = 0; count < LINE6_READ_WRITE_MAX_RETRIES; count++) {
> mdelay(LINE6_READ_WRITE_STATUS_DELAY);
>
> ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), 0x67,
> @@ -333,9 +335,16 @@ int line6_read_data(struct usb_line6 *line6, u16
> address, void *data,
> "receive length failed (error %d)\n", ret);
> return ret;
> }
> - } while (len == 0xff);
>
> - if (len != datalen) {
> + if (len != 0xff)
> + break;
> + }
> +
> + if (len == 0xff) {
> + dev_err(line6->ifcdev, "read failed after %d retries\n",
> + count);
> + return -EIO;
> + } else if (len != datalen) {
> /* should be equal or something went wrong */
> dev_err(line6->ifcdev,
> "length mismatch (expected %d, got %d)\n",
> @@ -367,6 +376,7 @@ int line6_write_data(struct usb_line6 *line6, u16
> address, void *data,
> struct usb_device *usbdev = line6->usbdev;
> int ret;
> unsigned char status;
> + int count;
>
> ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), 0x67,
> USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
> @@ -379,7 +389,7 @@ int line6_write_data(struct usb_line6 *line6, u16
> address, void *data,
> return ret;
> }
>
> - do {
> + for (count = 0; count < LINE6_READ_WRITE_MAX_RETRIES; count++) {
> mdelay(LINE6_READ_WRITE_STATUS_DELAY);
>
> ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0),
> @@ -394,9 +404,16 @@ int line6_write_data(struct usb_line6 *line6, u16
> address, void *data,
> "receiving status failed (error %d)\n", ret);
> return ret;
> }
> - } while (status == 0xff);
>
> - if (status != 0) {
> + if (status != 0xff)
> + break;
> + }
> +
> + if (status == 0xff) {
> + dev_err(line6->ifcdev, "write failed after %d retries\n",
> + count);
> + return -EIO;
> + } else if (status != 0) {
> dev_err(line6->ifcdev, "write failed (error %d)\n", ret);
> return -EINVAL;
> }
> --
> 2.1.0
>
--
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 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote: > well, ->prio and ->pid are already printed by sched tracepoints > and their meaning depends on scheduler. So users taking that > into account. Right, so trace_events were/are root only, and root 'should' be in the root pid namespace, and therefore pid magically works. And I'm not sure, but I don't think the 'nested' root available from containers should have access to ftrace, so that should not be an issue. Perf tries real hard to present PERF_SAMPLE_PID data in the pid namespace of the task that created the event. As to prio; yes this is a prime example of suck, I would love to change that but cannot :-(. The only solace I have is that everybody who is relying on it is broken. There is a very good reason I'm against adding more tracepoints to the scheduler, its a nightmare. -- 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 3/3] firmware: dmi_scan: use full dmi version for SMBIOS3
New SMBIOS3 spec adds additional field for versioning - docrev.
The docrev identifies the revision of a specification implemented in
the table structures, so display SMBIOS version > 3 in format,
like: 3.22.1
It's not affect on other part of code because version number
is analyzed using comparing, and it's obvious that 0x000208 is less
than 0x030201 for example.
Signed-off-by: Ivan Khoronzhuk
---
drivers/firmware/dmi_scan.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 952e95c..e4a2d25 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -17,7 +17,7 @@
*/
static const char dmi_empty_string[] = "";
-static u16 __initdata dmi_ver;
+static u32 dmi_ver __initdata;
static u32 dmi_len;
static u16 dmi_num;
/*
@@ -534,7 +534,8 @@ static int __init dmi_smbios3_present(const u8 *buf)
{
if (memcmp(buf, "_SM3_", 5) == 0 &&
buf[6] < 32 && dmi_checksum(buf, buf[6])) {
- dmi_ver = get_unaligned_be16(buf + 7);
+ dmi_ver = get_unaligned_be32(buf + 6);
+ dmi_ver &= 0xFF;
dmi_len = get_unaligned_le32(buf + 12);
dmi_base = get_unaligned_le64(buf + 16);
smbios_header_size = buf[6];
@@ -553,8 +554,9 @@ static int __init dmi_smbios3_present(const u8 *buf)
dmi_num = dmi_len / 4;
if (dmi_walk_early(dmi_decode) == 0) {
- pr_info("SMBIOS %d.%d present.\n",
- dmi_ver >> 8, dmi_ver & 0xFF);
+ pr_info("SMBIOS %d.%d.%d present.\n",
+ dmi_ver >> 16, (dmi_ver >> 8) & 0xFF,
+ dmi_ver & 0xFF);
dmi_format_ids(dmi_ids_string, sizeof(dmi_ids_string));
pr_debug("DMI: %s\n", dmi_ids_string);
return 0;
--
1.9.1
--
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/3] firmware: dmi_scan: fix dmi_len type
According to SMBIOSv3 specification the length of DMI table can be up to 32bits wide. So use appropriate type to avoid overflow. It's obvious that dmi_num theoretically can be more than u16 also, so it's can be changed to u32 or at least it's better to use int instead of u16, but on that moment I cannot imagine dmi structure count more than 65535 and it can require changing type of vars that work with it. So I didn't correct it. Signed-off-by: Ivan Khoronzhuk --- drivers/firmware/dmi_scan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c index fb16203..952e95c 100644 --- a/drivers/firmware/dmi_scan.c +++ b/drivers/firmware/dmi_scan.c @@ -18,7 +18,7 @@ static const char dmi_empty_string[] = ""; static u16 __initdata dmi_ver; -static u16 dmi_len; +static u32 dmi_len; static u16 dmi_num; /* * Catch too early calls to dmi_check_system(): -- 1.9.1 -- 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: 1e918876 breaks r8169 (linux-3.18+)
Hi, > > > Since linux-3.18.0, r8169 is having problems driving one of my add-on > > > PCIe NICs. The interface is losing link for several seconds at a time, > > > the frequency being about once a minute when the traffic is high. > > > > > > The first loss of link is accompanied by the message "NETDEV WATCHDOG: > > > eth1 (r8169): transmit queue 0 timed out" and a call trace, while > > > subsequent occurrences only report "r8169 :01:00.0 eth1: link up" > > > (w/o the complementary "link down" message). > > > > > > I've traced the culprit down to commit 1e918876, "r8169: add support > > > for Byte Queue Limits" by Florian Westphal . Reverting > > > the patch appears to fix the problem on linux-3.18.5. > > > The same issue might already have been reported by Marco Berizzi here: > > > http://lkml.org/lkml/2014/12/11/65 > > > > Thanks for reporting this! I'm no lkml subscriber and thus did not > > see earlier report. > > > > I'll try to reproduce this but unfortunately I am currently travelling > > and won't have access to my r8169 nic until Feb 10th. > > I tried to reproduce this without success so far on my RTL8168d/8111d device. I was afraid it might come to this. Of all the ~15 r8169 interfaces (mostly onboard) I've got running in about 10 machines, only a single one is affected. > I've been running 40 parallel netperf TCP_STREAM tests (1gbit) for the > last 5 hours and so far I saw no watchdog tx timeouts. > > I'll keep this running for a day or so to see if it just takes more time > to trigger. Ok, but if the bug were to manifest itself in the same manner as it does over here, it wouldn't require so much pressure. > Do you use any "special" settings (e.g. offload features off, mtu > 1500, > etc)? Nothing special. modprobe r8169 nameif eth1 xx:xx:xx:xx:xx:xx ip link set eth1 up ip addr add 192.168.x.y/24 brd + dev eth1 And that's it, really. Seeya, -- Tomáš Szépe -- 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/3] firmware: dmi_scan: use direct access to static vars
There is no reason to pass static vars to function that can use
only them.
The dmi_table() can use only dmi_len and dmi_num static vars, so use
them directly. In this case we can freely change their type in one
place and slightly decrease redundancy.
Signed-off-by: Ivan Khoronzhuk
---
drivers/firmware/dmi_scan.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index d55c712..fb16203 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -18,6 +18,8 @@
static const char dmi_empty_string[] = "";
static u16 __initdata dmi_ver;
+static u16 dmi_len;
+static u16 dmi_num;
/*
* Catch too early calls to dmi_check_system():
*/
@@ -78,7 +80,7 @@ static const char * __init dmi_string(const struct dmi_header
*dm, u8 s)
* We have to be cautious here. We have seen BIOSes with DMI pointers
* pointing to completely the wrong place for example
*/
-static void dmi_table(u8 *buf, int len, int num,
+static void dmi_table(u8 *buf,
void (*decode)(const struct dmi_header *, void *),
void *private_data)
{
@@ -89,7 +91,8 @@ static void dmi_table(u8 *buf, int len, int num,
* Stop when we see all the items the table claimed to have
* OR we run off the end of the table (also happens)
*/
- while ((i < num) && (data - buf + sizeof(struct dmi_header)) <= len) {
+ while ((i < dmi_num) && (data - buf + sizeof(struct dmi_header))
+ <= dmi_len) {
const struct dmi_header *dm = (const struct dmi_header *)data;
/*
@@ -104,9 +107,9 @@ static void dmi_table(u8 *buf, int len, int num,
* table in dmi_decode or dmi_string
*/
data += dm->length;
- while ((data - buf < len - 1) && (data[0] || data[1]))
+ while ((data - buf < dmi_len - 1) && (data[0] || data[1]))
data++;
- if (data - buf < len - 1)
+ if (data - buf < dmi_len - 1)
decode(dm, private_data);
data += 2;
i++;
@@ -116,8 +119,6 @@ static void dmi_table(u8 *buf, int len, int num,
static u8 smbios_header[32];
static int smbios_header_size;
static phys_addr_t dmi_base;
-static u16 dmi_len;
-static u16 dmi_num;
static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,
void *))
@@ -128,7 +129,7 @@ static int __init dmi_walk_early(void (*decode)(const
struct dmi_header *,
if (buf == NULL)
return -1;
- dmi_table(buf, dmi_len, dmi_num, decode, NULL);
+ dmi_table(buf, decode, NULL);
add_device_randomness(buf, dmi_len);
@@ -908,7 +909,7 @@ int dmi_walk(void (*decode)(const struct dmi_header *, void
*),
if (buf == NULL)
return -1;
- dmi_table(buf, dmi_len, dmi_num, decode, private_data);
+ dmi_table(buf, decode, private_data);
dmi_unmap(buf);
return 0;
--
1.9.1
--
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/3] firmware: dmi_scan: add some SMBIOSv3 corrections
This series adds corrections to dmi_scan: - extends version to be like 3.4.5 format - fix dmi_len to be 32 bit wide Ivan Khoronzhuk (3): firmware: dmi_scan: use direct access to static vars firmware: dmi_scan: fix dmi_len type firmware: dmi_scan: use full dmi version for SMBIOS3 drivers/firmware/dmi_scan.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) -- 1.9.1 -- 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 2/3] firmware: dmi_scan: fix dmi_len type
On 11 February 2015 at 17:46, Ivan Khoronzhuk wrote: > According to SMBIOSv3 specification the length of DMI table can be > up to 32bits wide. So use appropriate type to avoid overflow. > > It's obvious that dmi_num theoretically can be more than u16 also, > so it's can be changed to u32 or at least it's better to use int > instead of u16, but on that moment I cannot imagine dmi structure > count more than 65535 and it can require changing type of vars that > work with it. So I didn't correct it. > > Signed-off-by: Ivan Khoronzhuk Acked-by: Ard Biesheuvel This should get a cc stable as well. -- Ard. > --- > drivers/firmware/dmi_scan.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c > index fb16203..952e95c 100644 > --- a/drivers/firmware/dmi_scan.c > +++ b/drivers/firmware/dmi_scan.c > @@ -18,7 +18,7 @@ > static const char dmi_empty_string[] = ""; > > static u16 __initdata dmi_ver; > -static u16 dmi_len; > +static u32 dmi_len; > static u16 dmi_num; > /* > * Catch too early calls to dmi_check_system(): > -- > 1.9.1 > -- 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 3/3] firmware: dmi_scan: use full dmi version for SMBIOS3
On 11 February 2015 at 17:46, Ivan Khoronzhuk
wrote:
> New SMBIOS3 spec adds additional field for versioning - docrev.
> The docrev identifies the revision of a specification implemented in
> the table structures, so display SMBIOS version > 3 in format,
> like: 3.22.1
>
> It's not affect on other part of code because version number
> is analyzed using comparing, and it's obvious that 0x000208 is less
> than 0x030201 for example.
>
I don't think the spec forbids passing a 3.0+ table using the legacy
32-bit entry point, in which case the packing of the version could
potentially become a problem.
I don't care deeply about the docrev, so I think we could drop this
patch, but if others feel differently, could we at least pack the
version in a consistent manner (i.e., always account for docrev, and
set it to 0 if the 32-bit entry point is used?)
--
Ard.
> Signed-off-by: Ivan Khoronzhuk
> ---
> drivers/firmware/dmi_scan.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 952e95c..e4a2d25 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -17,7 +17,7 @@
> */
> static const char dmi_empty_string[] = "";
>
> -static u16 __initdata dmi_ver;
> +static u32 dmi_ver __initdata;
> static u32 dmi_len;
> static u16 dmi_num;
> /*
> @@ -534,7 +534,8 @@ static int __init dmi_smbios3_present(const u8 *buf)
> {
> if (memcmp(buf, "_SM3_", 5) == 0 &&
> buf[6] < 32 && dmi_checksum(buf, buf[6])) {
> - dmi_ver = get_unaligned_be16(buf + 7);
> + dmi_ver = get_unaligned_be32(buf + 6);
> + dmi_ver &= 0xFF;
> dmi_len = get_unaligned_le32(buf + 12);
> dmi_base = get_unaligned_le64(buf + 16);
> smbios_header_size = buf[6];
> @@ -553,8 +554,9 @@ static int __init dmi_smbios3_present(const u8 *buf)
> dmi_num = dmi_len / 4;
>
> if (dmi_walk_early(dmi_decode) == 0) {
> - pr_info("SMBIOS %d.%d present.\n",
> - dmi_ver >> 8, dmi_ver & 0xFF);
> + pr_info("SMBIOS %d.%d.%d present.\n",
> + dmi_ver >> 16, (dmi_ver >> 8) & 0xFF,
> + dmi_ver & 0xFF);
> dmi_format_ids(dmi_ids_string,
> sizeof(dmi_ids_string));
> pr_debug("DMI: %s\n", dmi_ids_string);
> return 0;
> --
> 1.9.1
>
--
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] ath9k_htc: add adaptive usb receive flow control to repair soft lockup with monitor mode
The ath9k_hif_usb_rx_cb function excute on the interrupt context, and
ath9k_rx_tasklet excute
on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more
chance to excute than
ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf receive list is
always full,
and the do {}while(true) loop will not be break. The kernel get a soft lockup
panic.
[59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
[kworker/0:0:30609]
[59011.030560] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.858522] Kernel panic - not syncing: softlockup: hung tasks
[59014.038891] Exception stack(0xdf4bbc38 to 0xdf4bbc80)
[59014.046834] bc20:
de57b950 6113
[59014.059579] bc40: bb32bb32 6113 de57b948 de57b500 dc7bb440
df4bbcd0
[59014.072337] bc60: de57b950 6113 df4bbcd0 df4bbc80 c04c259d c04c25a0
6133
[59014.085233] [] (__irq_svc+0x3b/0x5c) from []
(_raw_spin_unlock_irqrestore+0xc/0x10)
[59014.100437] [] (_raw_spin_unlock_irqrestore+0xc/0x10) from
[] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc])
[59014.118267] [] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from
[] (tasklet_action+0x3b/0x98)
[59014.134132] [] (tasklet_action+0x3b/0x98) from []
(__do_softirq+0x99/0x16c)
[59014.147784] [] (__do_softirq+0x99/0x16c) from []
(irq_exit+0x5b/0x5c)
[59014.160653] [] (irq_exit+0x5b/0x5c) from []
(handle_IRQ+0x37/0x78)
[59014.173124] [] (handle_IRQ+0x37/0x78) from []
(omap3_intc_handle_irq+0x5f/0x68)
[59014.187225] [] (omap3_intc_handle_irq+0x5f/0x68) from
[](__irq_svc+0x3b/0x5c)
This bug can be see with low performance board, such as uniprocessor beagle
bone board. Add some debug
message in the ath9k_hif_usb_rx_cb function may trigger this bug quickly.
Signed-off-by: Yuwei Zheng
---
Changes since v1:
- Add aurfc_active flag to stop delayed submit while
ath9k_hif_usb_dealloc_rx_urbs called.
- Add spinlock aurfc_lock to protect aurfc_delayed_work and aurfc_active.
- Add mod_delayed_work to trigger aurfc_submit_handler excuted immediately
while rx_buf list is empty.
- Add flush_delayed_work to wait the aurfc_submit_handler finish.
drivers/net/wireless/ath/ath9k/hif_usb.c | 78 +++---
drivers/net/wireless/ath/ath9k/hif_usb.h | 13 +
drivers/net/wireless/ath/ath9k/htc.h | 19 +++
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 53 +
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 58 +++
5 files changed, 214 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 8e7153b..2e73e19 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -640,6 +640,7 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
struct hif_device_usb *hif_dev =
usb_get_intfdata(usb_ifnum_to_if(urb->dev, 0));
int ret;
+ int delay;
if (!skb)
return;
@@ -658,7 +659,6 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
default:
goto resubmit;
}
-
if (likely(urb->actual_length != 0)) {
skb_put(skb, urb->actual_length);
ath9k_hif_usb_rx_stream(hif_dev, skb);
@@ -667,12 +667,23 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
resubmit:
skb_reset_tail_pointer(skb);
skb_trim(skb, 0);
-
- usb_anchor_urb(urb, _dev->rx_submitted);
- ret = usb_submit_urb(urb, GFP_ATOMIC);
- if (ret) {
- usb_unanchor_urb(urb);
- goto free;
+ spin_lock(_dev->aurfc_lock);
+ /* submit the urb more slowly for flow control */
+ if (atomic_read(_dev->aurfc_submit_delay) > 0 &&
+ hif_dev->aurfc_active == 1) {
+ usb_anchor_urb(urb, _dev->rx_delayed_submitted);
+ delay = atomic_read(_dev->aurfc_submit_delay);
+ schedule_delayed_work(_dev->aurfc_delayed_work,
+ msecs_to_jiffies(delay));
+ spin_unlock(_dev->aurfc_lock);
+ } else {
+ spin_unlock(_dev->aurfc_lock);
+ usb_anchor_urb(urb, _dev->rx_submitted);
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret) {
+ usb_unanchor_urb(urb);
+ goto free;
+ }
}
return;
@@ -818,9 +829,53 @@ err:
return -ENOMEM;
}
+static void aurfc_submit_handler(struct work_struct *work)
+{
+ struct hif_device_usb *hif_dev =
+ container_of(work,
+struct hif_device_usb,
+aurfc_delayed_work.work);
+ struct urb *urb = NULL;
+ struct sk_buff *skb = NULL;
+ int ret;
+ int loop_times = 0;
+
+
Re: intensive IO on usb-storage device causing system lock
It seems the problem is also triggerable without rtorrent, but other tools like git when checking out lots of files (in the kernel git repository for example). -- 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 3/3] firmware: dmi_scan: use full dmi version for SMBIOS3
On 02/11/2015 11:55 AM, Ard Biesheuvel wrote: On 11 February 2015 at 17:46, Ivan Khoronzhuk wrote: New SMBIOS3 spec adds additional field for versioning - docrev. The docrev identifies the revision of a specification implemented in the table structures, so display SMBIOS version > 3 in format, like: 3.22.1 It's not affect on other part of code because version number is analyzed using comparing, and it's obvious that 0x000208 is less than 0x030201 for example. I don't think the spec forbids passing a 3.0+ table using the legacy 32-bit entry point, in which case the packing of the version could potentially become a problem. I don't care deeply about the docrev, so I think we could drop this patch, but if others feel differently, could we at least pack the version in a consistent manner (i.e., always account for docrev, and set it to 0 if the 32-bit entry point is used?) If others are OK, I can add docrev for 32 bit 3+ versions. -- 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] ath9k_htc: add adaptive usb receive flow control to repair soft lockup with monitor mode
On 三, 2015-02-11 at 11:20 +0200, Kalle Valo wrote:
> Yuwei Zheng writes:
>
> > The ath9k_hif_usb_rx_cb function excute on the interrupt context, and
> > ath9k_rx_tasklet excute
> > on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more
> > chance to excute than
> > ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf receive list is
> > always full,
> > and the do {}while(true) loop will not be break. The kernel get a soft
> > lockup panic.
> >
> > [59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
> > [kworker/0:0:30609]
> > [59011.030560] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
> > [59013.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
> > [59013.858522] Kernel panic - not syncing: softlockup: hung tasks
> >
> > [59014.038891] Exception stack(0xdf4bbc38 to 0xdf4bbc80)
> > [59014.046834] bc20:
> > de57b950 6113
> > [59014.059579] bc40: bb32bb32 6113 de57b948 de57b500 dc7bb440
> > df4bbcd0
> > [59014.072337] bc60: de57b950 6113 df4bbcd0 df4bbc80 c04c259d c04c25a0
> > 6133
> > [59014.085233] [] (__irq_svc+0x3b/0x5c) from []
> > (_raw_spin_unlock_irqrestore+0xc/0x10)
> > [59014.100437] [] (_raw_spin_unlock_irqrestore+0xc/0x10) from
> > [] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc])
> > [59014.118267] [] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from
> > [] (tasklet_action+0x3b/0x98)
> > [59014.134132] [] (tasklet_action+0x3b/0x98) from []
> > (__do_softirq+0x99/0x16c)
> > [59014.147784] [] (__do_softirq+0x99/0x16c) from []
> > (irq_exit+0x5b/0x5c)
> > [59014.160653] [] (irq_exit+0x5b/0x5c) from []
> > (handle_IRQ+0x37/0x78)
> > [59014.173124] [] (handle_IRQ+0x37/0x78) from []
> > (omap3_intc_handle_irq+0x5f/0x68)
> > [59014.187225] [] (omap3_intc_handle_irq+0x5f/0x68) from
> > [](__irq_svc+0x3b/0x5c)
> >
> > This bug can be see with low performance board, such as uniprocessor beagle
> > bone board. Add some debug message in the ath9k_hif_usb_rx_cb
> > function may trigger this bug quickly.
> >
> > Signed-off-by: Yuwei Zheng
>
> The word wrapping is still wrong, please limit the line length to 72
> chars or so. This is the second time I'm mentioning that. Also add v2,
> v3 and so on when you send new versions of the patch, otherwise I will
> not know what version I should use. And even better if you add a
> changelog after "---" line.
>
> Documentation/SubmittingPatches should tell you all this.
>
I have modified and resubmited as you suggest.
Thanks.
--
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: [RFC] simple_char: New infrastructure to simplify chardev management
On Tue, 10 Feb 2015, Andy Lutomirski wrote: > This isn't adequately tested, and I don't have a demonstration (yet). > It's here for review for whether it's a good idea in the first place > and for weather the fully_dynamic mechanism is a good idea. [ ... snip ... ] > Signed-off-by: Andy Lutomirski Andy, thanks a lot, this really *is* needed. I am willing to port things I am responsible for (such as hidraw) to this once this gets merged. Acked-by: Jiri Kosina -- Jiri Kosina SUSE Labs -- 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 2/3] firmware: dmi_scan: fix dmi_len type
On 02/11/2015 11:53 AM, Ard Biesheuvel wrote: On 11 February 2015 at 17:46, Ivan Khoronzhuk wrote: According to SMBIOSv3 specification the length of DMI table can be up to 32bits wide. So use appropriate type to avoid overflow. It's obvious that dmi_num theoretically can be more than u16 also, so it's can be changed to u32 or at least it's better to use int instead of u16, but on that moment I cannot imagine dmi structure count more than 65535 and it can require changing type of vars that work with it. So I didn't correct it. Signed-off-by: Ivan Khoronzhuk Acked-by: Ard Biesheuvel This should get a cc stable as well. Pay attention that this patch has to be applied with patch 1/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] mfd: intel_soc_pmic: Add missing error check for devm_kzalloc
This patch add a missing check on the return value of devm_kzalloc, which would cause a NULL pointer dereference in a OOM situation. Signed-off-by: Kiran Padwal --- drivers/mfd/intel_soc_pmic_core.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mfd/intel_soc_pmic_core.c b/drivers/mfd/intel_soc_pmic_core.c index df7b064..80cef04 100644 --- a/drivers/mfd/intel_soc_pmic_core.c +++ b/drivers/mfd/intel_soc_pmic_core.c @@ -64,6 +64,9 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c, config = (struct intel_soc_pmic_config *)id->driver_data; pmic = devm_kzalloc(dev, sizeof(*pmic), GFP_KERNEL); + if (!pmic) + return -ENOMEM; + dev_set_drvdata(dev, pmic); pmic->regmap = devm_regmap_init_i2c(i2c, config->regmap_config); -- 1.7.9.5 -- 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 2/3] firmware: dmi_scan: fix dmi_len type
On 11 February 2015 at 18:10, Ivan Khoronzhuk wrote: > > On 02/11/2015 11:53 AM, Ard Biesheuvel wrote: >> >> On 11 February 2015 at 17:46, Ivan Khoronzhuk >> wrote: >>> >>> According to SMBIOSv3 specification the length of DMI table can be >>> up to 32bits wide. So use appropriate type to avoid overflow. >>> >>> It's obvious that dmi_num theoretically can be more than u16 also, >>> so it's can be changed to u32 or at least it's better to use int >>> instead of u16, but on that moment I cannot imagine dmi structure >>> count more than 65535 and it can require changing type of vars that >>> work with it. So I didn't correct it. >>> >>> Signed-off-by: Ivan Khoronzhuk >> >> Acked-by: Ard Biesheuvel >> >> This should get a cc stable as well. >> > > Pay attention that this patch has to be applied with patch 1/3. Good point. Actually, I don't really see the need for patch #1, even if I agree that it would have been better to write it like you have in the first place. But leaving the dmi_len as u16 is clearly a bug on my part, so that should be fixed. @Matt: any thoughts? -- 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] clk: Some fixes for the per-user clk API changes.
Hello, I found a couple of issues with todays' next (tag next-20150211) when booting an Exynos5420 Peach Pit Chromebook. These were regressions introduced when converting the clk API to return a per-user clk. This series is composed of the following trivial fixes: Javier Martinez Canillas (2): clk: Don't dereference parent clock if is NULL clk: composite: Set clk_core to composite rate and mux components drivers/clk/clk-composite.c | 2 ++ drivers/clk/clk.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) Best regards, Javier -- 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] clk: composite: Set clk_core to composite rate and mux components
Commit 035a61c314eb3 ("clk: Make clk API return per-user struct clk instances")
moved the clock state to struct clk_core to allow the clk API returning per
user clk instances so now the struct clk_hw .core field is used instead of .clk
for most operations.
But in case of composite clocks, the rate and mux components didn't have a .core
set which leads to a NULL pointer dereference in clk_mux_determine_rate_flags():
Unable to handle kernel NULL pointer dereference at virtual address 0034
pgd = c0004000
[0034] *pgd=
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.19.0-next-20150211-2-g1fb7f0e1150d #423
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
task: ee48 ti: ee488000 task.ti: ee488000
PC is at clk_mux_determine_rate_flags+0x14/0x19c
LR is at __clk_mux_determine_rate+0x24/0x2c
pc : []lr : []psr: a113
sp : ee489ce8 ip : ee489d84 fp : ee489d84
r10: 005c r9 : 0001 r8 : 016e3600
r7 : r6 : r5 : ee442200 r4 : ee440c98
r3 : r2 : r1 : 016e3600 r0 : ee440c98
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 4000406a DAC: 0015
Process swapper/0 (pid: 1, stack limit = 0xee488210)
Stack: (0xee489ce8 to 0xee48a000)
9ce0: 6113 ee440c98 ee442200
9d00: 016e3600 0001 005c ee489d84 c03a3734 ee489d80 ee489d84
9d20: c048b130 0400 c03a5798 ee489d80 ee489d84 c0607f60 ffea
9d40: 0001 0001 ee489d5c c003f844 c06e3340 ee402680 ee440d0c ed935000
9d60: 016e3600 0003 0001 005c eded3700 c03a11a0 ee489d80 ee489d84
9d80: 016e3600 ee402680 c05b413a eddc9900 016e3600 c03a1228
9da0: eddc9900 016e3600 c03a1c1c 016e3600 ed8c6710 c03d6ce4
9dc0: eded3400 c03c797c 0001 005c eded3700 eded3700
9de0: 05e0 0001 005c c03db8ac c06e7e54 c03c8f08 c06e7e64
9e00: c06b6e74 c06e7f64 05e0 c06e7df8 c06e5100 c06e7e6c c06e7f54
9e20: eebd9550 c06e7da0 c06e7e54 ee7b5010 c06e7da0
9e40: eddc9690 c06e7db4 c06b6e74 0097 c03d4398 ee7b5010
9e60: eebd9550 c06e7da0 c03db824 ee7b5010 fffe c06e7db4 c0299c7c
9e80: ee7b5010 c072a05c c0298858 ee7b5010 c06e7db4 ee7b5044
9ea0: eddc9580 c0298a04 c06e7db4 c0298978 c02971d4 ee405c78 ee732b40
9ec0: c06e7db4 eded3800 c06d6738 c0298044 c0608300 c06e7db4 c06e7db4
9ee0: c06beb58 c06beb58 c0299024 c068dd00 c0008944
9f00: 0038 c049013c ee462200 c0711920 ee48 6113 c06c2cb0
9f20: c06c2cb0 6113 ef7fcafc c0640194 c00389ec
9f40: c05ec3a8 c063f824 0006 0006 c06c2c50 c0696444 0006 c0696424
9f60: c06ee1c0 c066b588 c06b6e74 0097 c066bd44 0006 0006
9f80: c066b588 c003d684 c0481938
9fa0: c0481940 c000e680
9fc0:
9fe0: 0013
[] (clk_mux_determine_rate_flags) from []
(__clk_mux_determine_rate+0x24/0x2c)
[] (__clk_mux_determine_rate) from []
(clk_composite_determine_rate+0xbc/0x238)
[] (clk_composite_determine_rate) from []
(clk_core_round_rate_nolock+0x5c/0x9c)
[] (clk_core_round_rate_nolock) from []
(__clk_round_rate+0x38/0x40)
[] (__clk_round_rate) from [] (clk_round_rate+0x20/0x38)
[] (clk_round_rate) from []
(max98090_dai_set_sysclk+0x34/0x118)
[] (max98090_dai_set_sysclk) from []
(snd_soc_dai_set_sysclk+0x38/0x80)
[] (snd_soc_dai_set_sysclk) from []
(snow_late_probe+0x24/0x48)
[] (snow_late_probe) from []
(snd_soc_register_card+0xf04/0x1070)
[] (snd_soc_register_card) from []
(devm_snd_soc_register_card+0x30/0x64)
[] (devm_snd_soc_register_card) from []
(snow_probe+0x68/0xcc)
[] (snow_probe) from [] (platform_drv_probe+0x48/0x98)
[] (platform_drv_probe) from []
(driver_probe_device+0x114/0x234)
[] (driver_probe_device) from [] (__driver_attach+0x8c/0x90)
[] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
[] (bus_for_each_dev) from [] (bus_add_driver+0xd8/0x1cc)
[] (bus_add_driver) from [] (driver_register+0x78/0xf4)
[] (driver_register) from [] (do_one_initcall+0x80/0x1d0)
[] (do_one_initcall) from []
(kernel_init_freeable+0x10c/0x1d8)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4)
[] (kernel_init) from [] (ret_from_fork+0x14/0x34)
Code: e24dd00c e5907000 e1a08001 e88d000c (e5970034)
---[ end trace 825e9bbb0898d421 ]---
Fixes: 035a61c314eb3 ("clk: Make clk API return per-user struct clk instances")
Signed-off-by: Javier Martinez Canillas
---
Hello,
I set the rate and mux components' .core in clk_composite_determine_rate()
because that is the le
[PATCH 1/2] clk: Don't dereference parent clock if is NULL
The clock passed as an argument to clk_mux_determine_rate_flags() can
not have a parent clock if is either a root clock or an orphan.
In those cases parent is NULL so parent->hw shouldn't be dereferenced.
Fixes: 035a61c314eb3 ("clk: Make clk API return per-user struct clk instances")
Signed-off-by: Javier Martinez Canillas
---
drivers/clk/clk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 7f53166af5e6..7bd8893c94d6 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -799,7 +799,7 @@ clk_mux_determine_rate_flags(struct clk_hw *hw, unsigned
long rate,
/* if NO_REPARENT flag set, pass through to current parent */
if (core->flags & CLK_SET_RATE_NO_REPARENT) {
parent = core->parent;
- if (core->flags & CLK_SET_RATE_PARENT)
+ if (core->flags & CLK_SET_RATE_PARENT && parent)
best = __clk_determine_rate(parent->hw, rate,
min_rate, max_rate);
else if (parent)
--
2.1.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 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
On Tue, Feb 10, 2015 at 04:22:50PM -0800, Alexei Starovoitov wrote: > > It would need to do more that that. It may have to calculate the value > > that it returns, as the internal value may be different with different > > kernels. > > back to 'prio'... the 'prio' accessible from the program > should be the same 'prio' that we're storing inside task_struct. Its not, task_struct::prio is an entirely different value than the one used in sched_param::sched_priority / sched_attr::sched_priority. And the 'problem' is, prio is only relevant to SCHED_RR/SCHED_FIFO tasks, we have more classes. > No extra conversions. We're not going to add runtime/space overhead to the kernel just because someone might maybe someday trace the kernel. That leaves the option of either tracing the kernel internal value and userspace will just have to deal with it, or making the tracepoint more expensive by having it do the conversion. Now the big question is, what do we do when we add/extend a scheduling class and have more parameters? We cannot change the tracepoint because userspace assumes format. And I simply refuse to add a second -- because that will end up being a third and fourth etc.. -- tracepoint right next to it with a different layout. Note that we just did add a class, we grew SCHED_DEADLINE a few releases ago, and that has 3 parameters (or 6 depending on how you look at it). You currently cannot 'debug' that with the existing tracepoints. In short, I loathe traceevents, they're more trouble than they're worth. Now I do love the infrastructure, its very useful debugging, but that's all with local hacks that will never see the light of day. -- 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] f2fs: use spinlock for segmap_lock instead of rwlock
rwlock can provide better concurrency when there are much more readers than
writers because readers can hold the rwlock simultaneously.
But now, for segmap_lock rwlock in struct free_segmap_info, there is only one
reader 'mount' from below call path:
->f2fs_fill_super
->build_segment_manager
->build_dirty_segmap
->init_dirty_segmap
->find_next_inuse
read_lock
...
read_unlock
Now that our concurrency can not be improved since there is no other reader for
this lock, we do not need to use rwlock_t type for segmap_lock, let's replace it
with spinlock_t type.
Signed-off-by: Chao Yu
---
fs/f2fs/segment.c | 6 +++---
fs/f2fs/segment.h | 18 +-
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index c542f63..5a6c818 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -800,7 +800,7 @@ static void get_new_segment(struct f2fs_sb_info *sbi,
int go_left = 0;
int i;
- write_lock(_i->segmap_lock);
+ spin_lock(_i->segmap_lock);
if (!new_sec && ((*newseg + 1) % sbi->segs_per_sec)) {
segno = find_next_zero_bit(free_i->free_segmap,
@@ -873,7 +873,7 @@ got_it:
f2fs_bug_on(sbi, test_bit(segno, free_i->free_segmap));
__set_inuse(sbi, segno);
*newseg = segno;
- write_unlock(_i->segmap_lock);
+ spin_unlock(_i->segmap_lock);
}
static void reset_curseg(struct f2fs_sb_info *sbi, int type, int modified)
@@ -1920,7 +1920,7 @@ static int build_free_segmap(struct f2fs_sb_info *sbi)
free_i->start_segno = GET_SEGNO_FROM_SEG0(sbi, MAIN_BLKADDR(sbi));
free_i->free_segments = 0;
free_i->free_sections = 0;
- rwlock_init(_i->segmap_lock);
+ spin_lock_init(_i->segmap_lock);
return 0;
}
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 421d579..9002df1 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -207,7 +207,7 @@ struct free_segmap_info {
unsigned int start_segno; /* start segment number logically */
unsigned int free_segments; /* # of free segments */
unsigned int free_sections; /* # of free sections */
- rwlock_t segmap_lock; /* free segmap lock */
+ spinlock_t segmap_lock; /* free segmap lock */
unsigned long *free_segmap; /* free segment bitmap */
unsigned long *free_secmap; /* free section bitmap */
};
@@ -318,9 +318,9 @@ static inline unsigned int find_next_inuse(struct
free_segmap_info *free_i,
unsigned int max, unsigned int segno)
{
unsigned int ret;
- read_lock(_i->segmap_lock);
+ spin_lock(_i->segmap_lock);
ret = find_next_bit(free_i->free_segmap, max, segno);
- read_unlock(_i->segmap_lock);
+ spin_unlock(_i->segmap_lock);
return ret;
}
@@ -331,7 +331,7 @@ static inline void __set_free(struct f2fs_sb_info *sbi,
unsigned int segno)
unsigned int start_segno = secno * sbi->segs_per_sec;
unsigned int next;
- write_lock(_i->segmap_lock);
+ spin_lock(_i->segmap_lock);
clear_bit(segno, free_i->free_segmap);
free_i->free_segments++;
@@ -340,7 +340,7 @@ static inline void __set_free(struct f2fs_sb_info *sbi,
unsigned int segno)
clear_bit(secno, free_i->free_secmap);
free_i->free_sections++;
}
- write_unlock(_i->segmap_lock);
+ spin_unlock(_i->segmap_lock);
}
static inline void __set_inuse(struct f2fs_sb_info *sbi,
@@ -362,7 +362,7 @@ static inline void __set_test_and_free(struct f2fs_sb_info
*sbi,
unsigned int start_segno = secno * sbi->segs_per_sec;
unsigned int next;
- write_lock(_i->segmap_lock);
+ spin_lock(_i->segmap_lock);
if (test_and_clear_bit(segno, free_i->free_segmap)) {
free_i->free_segments++;
@@ -373,7 +373,7 @@ static inline void __set_test_and_free(struct f2fs_sb_info
*sbi,
free_i->free_sections++;
}
}
- write_unlock(_i->segmap_lock);
+ spin_unlock(_i->segmap_lock);
}
static inline void __set_test_and_inuse(struct f2fs_sb_info *sbi,
@@ -381,13 +381,13 @@ static inline void __set_test_and_inuse(struct
f2fs_sb_info *sbi,
{
struct free_segmap_info *free_i = FREE_I(sbi);
unsigned int secno = segno / sbi->segs_per_sec;
- write_lock(_i->segmap_lock);
+ spin_lock(_i->segmap_lock);
if (!test_and_set_bit(segno, free_i->free_segmap)) {
free_i->free_segments--;
if (!test_and_set_bit(secno, free_i->free_secmap))
free_i->free_sections--;
}
- write_unlock(_i->segmap_lock);
+ spin_unlock(_i->segmap_lock);
}
static inline void get_sit_bitmap(struct f2fs_sb_info *sbi,
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe
Re: [RFC PATCH 6/9] livepatch: create per-task consistency model
On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
[...]
> @@ -38,14 +39,34 @@ static void notrace klp_ftrace_handler(unsigned long ip,
> ops = container_of(fops, struct klp_ops, fops);
>
> rcu_read_lock();
> +
> func = list_first_or_null_rcu(>func_stack, struct klp_func,
> stack_node);
> - rcu_read_unlock();
>
> if (WARN_ON_ONCE(!func))
> - return;
> + goto unlock;
> +
> + if (unlikely(func->transition)) {
> + /* corresponding smp_wmb() is in klp_init_transition() */
> + smp_rmb();
> +
> + if (current->klp_universe == KLP_UNIVERSE_OLD) {
> + /*
> + * Use the previously patched version of the function.
> + * If no previous patches exist, use the original
> + * function.
> + */
> + func = list_entry_rcu(func->stack_node.next,
> + struct klp_func, stack_node);
> +
> + if (>stack_node == >func_stack)
> + goto unlock;
> + }
> + }
>
> klp_arch_set_pc(regs, (unsigned long)func->new_func);
> +unlock:
> + rcu_read_unlock();
> }
I decided to understand the code more before answering the email about the
race and found another problem. I think.
Imagine we patched some function foo() with foo_1() from patch_1 and now
we'd like to patch it again with foo_2() in patch_2. __klp_enable_patch
calls klp_init_transition which sets klp_universe for all processes to
KLP_UNIVERSE_OLD and marks the foo_2() for transition (it is gonna be 1).
Then __klp_enable_patch adds foo_2() to the RCU-protected list for foo().
BUT what if somebody calls foo() right between klp_init_transition and
the loop in __klp_enable_patch? The ftrace handler first returns the
first entry in the list which is foo_1() (foo_2() is still not present),
then it checks for func->transition. It is 1. It checks for
current->klp_universe which is KLP_UNIVERSE_OLD and so the next entry is
retrieved. There is no such and therefore foo() is called. This is
obviously wrong because foo_1() was expected.
Everything would work fine if one would call foo() before
klp_start_transition and after the loop in __klp_enable_patch. The
solution might be to move the setting of func->transition to
klp_start_transition, but this could break something different. I don't
know yet.
Am I wrong?
Miroslav
--
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 1/1] staging: unisys: Remove allocation from declaration line
On Wed, Feb 11, 2015 at 06:26:27AM +0800, Greg Kroah-Hartman wrote: > On Tue, Feb 10, 2015 at 02:02:14PM +0100, Quentin Lambert wrote: > > This patch removes allocation from declaration line because > > people are known to gloss over declarations. > > Again, who are these lazy people, and why are they reading kernel code? > >From my work with smatch: 1) Probably 70-80% of inconsistent NULL checking is when done in the initializer. I'm sending a patch for one of these today. 2) If there is an allocation in the initializer then it's more likely that the NULL check will be missing. Initializers are a blind spot that people do not read. It's not just one maintainer, it's consistent across the board. Also if you put an allocation in the initializer then it almost always has to be mangled to fit in 80 characters and it looks ugly. But after these patches then all the allocations fit naturally. Plus you have to have that blank line to separate the initialization paragraph from the paragraph with the check for allocation failure. Really, it is fairly uncommon to put an allocation in the initalizer. regards, dan carpenter -- 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] openvswitch: Add missing initialization in validate_and_copy_set_tun()
net/openvswitch/flow_netlink.c: In function ‘validate_and_copy_set_tun’:
net/openvswitch/flow_netlink.c:1749: warning: ‘err’ may be used uninitialized
in this function
If ipv4_tun_from_nlattr() returns a different positive value than
OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS, err will be uninitialized, and
validate_and_copy_set_tun() may return an undefined value instead of a
zero success indicator. Initialize err to zero to fix this.
Fixes: 1dd144cf5b4b47e1 ("openvswitch: Support VXLAN Group Policy extension")
Signed-off-by: Geert Uytterhoeven
---
net/openvswitch/flow_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 993281e6278dc829..3829328c5a7648bf 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -1746,7 +1746,7 @@ static int validate_and_copy_set_tun(const struct nlattr
*attr,
struct sw_flow_key key;
struct ovs_tunnel_info *tun_info;
struct nlattr *a;
- int err, start, opts_type;
+ int err = 0, start, opts_type;
ovs_match_init(, , NULL);
opts_type = ipv4_tun_from_nlattr(nla_data(attr), , false, log);
--
1.9.1
--
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] drivers: net: xgene: Make xgene_enet_of_match depend on CONFIG_OF
If CONFIG_NET_XGENE=y but CONFIG_OF=n:
drivers/net/ethernet/apm/xgene/xgene_enet_main.c:1033: warning:
‘xgene_enet_of_match’ defined but not used
Signed-off-by: Geert Uytterhoeven
---
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 44b15373d6b3e628..4de62b210c85bab8 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1030,12 +1030,14 @@ static const struct acpi_device_id
xgene_enet_acpi_match[] = {
MODULE_DEVICE_TABLE(acpi, xgene_enet_acpi_match);
#endif
+#ifdef CONFIG_OF
static struct of_device_id xgene_enet_of_match[] = {
{.compatible = "apm,xgene-enet",},
{},
};
MODULE_DEVICE_TABLE(of, xgene_enet_of_match);
+#endif
static struct platform_driver xgene_enet_driver = {
.driver = {
--
1.9.1
--
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 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
On Tue, Feb 10, 2015 at 04:53:59PM -0500, Steven Rostedt wrote: > > >> In the future we might add a tracepoint and pass a single > > >> pointer to interesting data struct to it. bpf programs will walk > > >> data structures 'as safe modules' via bpf_fetch*() methods > > >> without exposing it as ABI. > > > > > > Will this work if that structure changes? When the field we are looking > > > for no longer exists? > > > > bpf_fetch*() is the same mechanism as perf probe. > > If there is a mistake by user space tools, the program > > will be reading some junk, but it won't be crashing. > > But what if the userspace tool depends on that value returning > something meaningful. If it was meaningful in the past, it will have to > be meaningful in the future, even if the internals of the kernel make > it otherwise. We're compiling the BPF stuff against the 'current' kernel headers right? So would enforcing module versioning not be sufficient? We already break out-of-tree modules without a second thought, the module interface is not guaranteed. They just need to cope with it. Anything using the kernel headers to look into the kernel guts should be bound to the same rules. So if we think of BFP stuff as out-of-tree modules, and treat them the same, I see no problem. I'm sure some BFP 'scripts' will turn in the same right mess that out-of-tree modules are, with endless #ifdef version checks, but hey, not my problem ;-) -- 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] drivers/net: Use setup_timer and mod_timer
This patch introduces the use of functions setup_timer and mod_timer. This is done using Coccinelle and semantic patch used for this as follows: // @@ expression x,y,z,a,b; @@ -init_timer (); +setup_timer (, y, z); +mod_timer (, b); -x.function = y; -x.data = z; -x.expires = b; -add_timer(); // Signed-off-by: Vaishali Thakkar --- drivers/net/ethernet/3com/3c589_cs.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/3com/3c589_cs.c b/drivers/net/ethernet/3com/3c589_cs.c index f18647c..c5a3205 100644 --- a/drivers/net/ethernet/3com/3c589_cs.c +++ b/drivers/net/ethernet/3com/3c589_cs.c @@ -518,11 +518,8 @@ static int el3_open(struct net_device *dev) netif_start_queue(dev); tc589_reset(dev); - init_timer(>media); - lp->media.function = media_check; - lp->media.data = (unsigned long) dev; - lp->media.expires = jiffies + HZ; - add_timer(>media); + setup_timer(>media, media_check, (unsigned long)dev); + mod_timer(>media, jiffies + HZ); dev_dbg(>dev, "%s: opened, status %4.4x.\n", dev->name, inw(dev->base_addr + EL3_STATUS)); -- 1.9.1 -- 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] mailbox, pl320-ipc: fixup return type of wait_for_completion_timeout
return type of wait_for_completion_timeout is unsigned long not int. A
appropriately named variable of type unsigned long is added and the
assignments fixed up.
Signed-off-by: Nicholas Mc Guire
---
Patch was only compile tested with u300_defconfig + CONFIG_MAILBOX=y
CONFIG_PL320_MBOX=y
Patch is against 3.19.0 (localversion-next is -next-20150211)
drivers/mailbox/pl320-ipc.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
index f3755e0..b898264 100644
--- a/drivers/mailbox/pl320-ipc.c
+++ b/drivers/mailbox/pl320-ipc.c
@@ -88,14 +88,15 @@ static u32 __ipc_rcv(int mbox, u32 *data)
int pl320_ipc_transmit(u32 *data)
{
int ret;
+ unsigned long time_left;
mutex_lock(_m1_lock);
init_completion(_completion);
__ipc_send(IPC_TX_MBOX, data);
- ret = wait_for_completion_timeout(_completion,
+ time_left = wait_for_completion_timeout(_completion,
msecs_to_jiffies(1000));
- if (ret == 0) {
+ if (time_left == 0) {
ret = -ETIMEDOUT;
goto out;
}
--
1.7.10.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 v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Fri, Feb 6, 2015 at 2:34 AM, Bjorn Andersson wrote: >> Yep, will do as soon as I hear from Ohad on what to do with the patch >> "hwspinlock/core: maintain a list of registered hwspinlock banks" that I >> dropped from v7. Without that and dropping hwlock-base-id, I can't get >> the translations done. >> > > My suggestion is to replace the global id-tree with a list of hwlocks > and iterate over these if we ever get more than one driver registered. > As long as #hwlock-drivers < log(#total-hwlocks) this should be > faster. > > I would however argue that clients that would notice any kind of > difference are using the API incorrectly. > > Unfortunately this is a somewhat larger change than just slapping DT > support on the framework :/ I suspect we want to wait with framework changes until there's a real hardware use case justifying them. With regard to DT, however, we obviously do want to be prepared for multiple hwlock blocks even if they do not exist today. So how about adopting an approach where: - DT fully supports multi hwlock blocks (i.e. no global id field) - Framework left mostly unchanged at the moment. This means issuing an explicit error in case a secondary hwlock block shows up, and then hwlock id could trivially be the lock index. If multi hwlock hardware use case, or some new hwlock id translation requirements, do show up in the future, it's always easy to add framework support for it. At that point we'll know better what the requirements are, and framework changes would be justifiable. Thanks, Ohad. -- 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 v2 1/3] media/videobuf2-dma-sg: Fix handling of sg_table structure
When sg_alloc_table_from_pages() does not fail it returns a sg_table
structure with nents and nents_orig initialized to the same value.
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
The output of dma_map, should be used to transverse the scatter list.
dma_unmap_sg needs the value passed to dma_map_sg (nents_orig).
sg_free_tables uses also orig_nent.
This patch fix the file to follow this paradigm.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index b1838ab..40c330f 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -147,8 +147,9 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
long size,
* No need to sync to the device, this will happen later when the
* prepare() memop is called.
*/
- if (dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->nents,
-buf->dma_dir, ) == 0)
+ sgt->nents = dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
+ buf->dma_dir, );
+ if (!sgt->nents)
goto fail_map;
buf->handler.refcount = >refcount;
@@ -187,7 +188,7 @@ static void vb2_dma_sg_put(void *buf_priv)
dma_set_attr(DMA_ATTR_SKIP_CPU_SYNC, );
dprintk(1, "%s: Freeing buffer of %d pages\n", __func__,
buf->num_pages);
- dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->nents,
+ dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
buf->dma_dir, );
if (buf->vaddr)
vm_unmap_ram(buf->vaddr, buf->num_pages);
@@ -314,9 +315,11 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
unsigned long vaddr,
* No need to sync to the device, this will happen later when the
* prepare() memop is called.
*/
- if (dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->nents,
-buf->dma_dir, ) == 0)
+ sgt->nents = dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
+ buf->dma_dir, );
+ if (!sgt->nents)
goto userptr_fail_map;
+
return buf;
userptr_fail_map:
@@ -351,7 +354,8 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
dprintk(1, "%s: Releasing userspace buffer of %d pages\n",
__func__, buf->num_pages);
- dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir,
);
+ dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir,
+ );
if (buf->vaddr)
vm_unmap_ram(buf->vaddr, buf->num_pages);
sg_free_table(buf->dma_sgt);
@@ -502,7 +506,6 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
/* stealing dmabuf mutex to serialize map/unmap operations */
struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- int ret;
mutex_lock(lock);
@@ -521,8 +524,9 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
}
/* mapping to the client with new direction */
- ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dma_dir);
- if (ret <= 0) {
+ sgt->nents = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
+ dma_dir);
+ if (!sgt->nents) {
pr_err("failed to map scatterlist\n");
mutex_unlock(lock);
return ERR_PTR(-EIO);
--
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 v2 2/3] media/videobuf2-dma-contig: Save output from dma_map_sg
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index b481d20..bfb5917 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -299,7 +299,6 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
/* stealing dmabuf mutex to serialize map/unmap operations */
struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- int ret;
mutex_lock(lock);
@@ -318,8 +317,9 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
}
/* mapping to the client with new direction */
- ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dma_dir);
- if (ret <= 0) {
+ sgt->nents = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
+ dma_dir);
+ if (!sgt->nents) {
pr_err("failed to map scatterlist\n");
mutex_unlock(lock);
return ERR_PTR(-EIO);
--
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 v2 3/3] media/videobuf2-dma-vmalloc: Save output from dma_map_sg
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/videobuf2-vmalloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index bcde885..f92bc9e 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -287,7 +287,6 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
/* stealing dmabuf mutex to serialize map/unmap operations */
struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- int ret;
mutex_lock(lock);
@@ -306,8 +305,9 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
}
/* mapping to the client with new direction */
- ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dma_dir);
- if (ret <= 0) {
+ sgt->nents = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
+ dma_dir);
+ if (!sgt->nents) {
pr_err("failed to map scatterlist\n");
mutex_unlock(lock);
return ERR_PTR(-EIO);
--
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 1/1] Staging: dgnc: dgnc_tty: code style improvements
That looks kind of uglier than before. Please run your patch throught scripts/checkpatch.pl --strict. regards, dan carpenter -- 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] clockevents: Introduce mode specific callbacks
On Wed, Feb 11, 2015 at 11:24:53AM +0800, Viresh Kumar wrote:
> On 10 February 2015 at 22:15, Peter Zijlstra wrote:
> > On Wed, Feb 04, 2015 at 01:06:23PM +0530, Viresh Kumar wrote:
> >> + /*
> >> + * Mode transition callback(s): Only one of the two groups should be
> >> + * defined:
> >> + * - set_mode(), only for modes <= CLOCK_EVT_MODE_RESUME.
> >> + * - set_mode_{shutdown|periodic|oneshot|resume}().
> >> + */
> >> +static int clockevents_sanity_check(struct clock_event_device *dev)
> >> +{
> >> +}
> >
> > It appears to me you've not actually checked that condition outlined
> > above, a driver could set both the legacy and the new callbacks.
>
> Exactly for this reason I mentioned this in the logs:
>
> >> If the legacy ->set_mode() callback is provided, all mode specific
> >> callbacks would be ignored.
>
> So, either we can mention that in the code as well OR add code to
> check and WARN about that. Will do whatever looks better to you
> guys.
I think its better to be strict; esp. with new interfaces. It avoids
confusion.
Suppose a driver writer sees these new methods and thinks to use one
while still having the set_mode() one -- ie. he didn't actually read the
comment. We'd better make sure he fails and goes back to read it.
--
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/
bluetooth on n900 -- working patch
Hi!
Here's current version of the bluetooth patch, I hope I did not miss
anything. This time including dts changes, so that driver is active.
I have firmware in /lib/firmware/nokia/bcmfw.bin
Best regards,
Pavel
Signed-off-by: Pavel Machek
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..e9fde42 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,14 @@ Required properties:
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- compatible : should be "ti+brcm,omap3-uart,bcm2048" for bcm2048
+ bluetooth connected to OMAP3 serial
- ti,hwmods : Must be "uart", n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+
+Required properties for ti+brcm,omap3-uart,bcm2048:
+- reset-gpios : gpio for reset pin
+- host-wakeup-gpios : gpio for host wakeup
+- bluetooth-wakeup-gpios : gpio for bluetooth wakeup
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index b550c41..e19bbe8 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -821,9 +867,19 @@
};
{
+compatible = "ti+brcm,omap3-uart,bcm2048", "ti,omap3-uart";
interrupts-extended = < 73 _pmx_core OMAP3_UART2_RX>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+
+ clocks = <_fck>, <_ick>;
+ clock-names = "fck", "ick";
+
+ device {
+ reset-gpios = < 27 GPIO_ACTIVE_HIGH>; /* 91 */
+ host-wakeup-gpios = < 5 GPIO_ACTIVE_HIGH>; /* 101 */
+ bluetooth-wakeup-gpios = < 5 GPIO_ACTIVE_HIGH>; /* 37 */
+ };
};
{
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 01b7111..60e6d6b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -275,7 +275,8 @@
};
uart2: serial@4806c000 {
- compatible = "ti,omap3-uart";
+ // This is bluetooth on n900, ttyO1
+ compatible = "not-a-ti,omap3-not-a-uart";
reg = <0x4806c000 0x400>;
interrupts-extended = < 73>;
dmas = < 51 52>;
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 364f080..e1e1935 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -244,4 +244,14 @@ config BT_WILINK
Say Y here to compile support for Texas Instrument's WiLink7 driver
into the kernel or say M to compile it as module (btwilink).
+config BT_NOKIA_H4P
+ tristate "Nokia H4+ Extensions (H4P) driver"
+ help
+ Bluetooth HCI driver with H4 extensions. This driver provides
+ support for H4+ Bluetooth chip with vendor-specific H4 extensions.
+ It works on Broadcom based chip found in Nokia N900.
+
+ Say Y here to compile support for h4 extended devices into the kernel
+ or say M to compile it as module (nokia_h4p).
+
endmenu
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 9fe8a87..f1cc580 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -31,4 +31,8 @@ hci_uart-$(CONFIG_BT_HCIUART_ATH3K) += hci_ath.o
hci_uart-$(CONFIG_BT_HCIUART_3WIRE)+= hci_h5.o
hci_uart-objs := $(hci_uart-y)
+obj-$(CONFIG_BT_NOKIA_H4P) += nokia_h4p.o
+
+nokia_h4p-y:= nokia_core.o nokia_fw.o nokia_uart.o
+
ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/bluetooth/nokia_core.c b/drivers/bluetooth/nokia_core.c
new file mode 100644
index 000..ad461a9
--- /dev/null
+++ b/drivers/bluetooth/nokia_core.c
@@ -0,0 +1,1140 @@
+/*
+ * This file is part of Nokia H4P bluetooth driver
+ *
+ * Copyright (C) 2005-2008 Nokia Corporation.
+ * Copyright (C) 2014 Pavel Machek
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * Thanks to all the Nokia people that helped with this driver,
+ * including Ville Tervo and Roger Quadros.
+ *
+ * Power saving functionality was removed from this driver to make
+ * merging easier.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
Re: [PATCH v2 2/3] media/videobuf2-dma-contig: Save output from dma_map_sg
Hello,
On 2015-02-11 11:33, Ricardo Ribalda Delgado wrote:
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
Signed-off-by: Ricardo Ribalda Delgado
Reviewed-by: Marek Szyprowski
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index b481d20..bfb5917 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -299,7 +299,6 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
/* stealing dmabuf mutex to serialize map/unmap operations */
struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- int ret;
mutex_lock(lock);
@@ -318,8 +317,9 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
}
/* mapping to the client with new direction */
- ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dma_dir);
- if (ret <= 0) {
+ sgt->nents = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
+ dma_dir);
+ if (!sgt->nents) {
pr_err("failed to map scatterlist\n");
mutex_unlock(lock);
return ERR_PTR(-EIO);
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
--
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 1/3] media/videobuf2-dma-sg: Fix handling of sg_table structure
Hello,
On 2015-02-11 11:33, Ricardo Ribalda Delgado wrote:
When sg_alloc_table_from_pages() does not fail it returns a sg_table
structure with nents and nents_orig initialized to the same value.
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
The output of dma_map, should be used to transverse the scatter list.
dma_unmap_sg needs the value passed to dma_map_sg (nents_orig).
sg_free_tables uses also orig_nent.
This patch fix the file to follow this paradigm.
Signed-off-by: Ricardo Ribalda Delgado
Reviewed-by: Marek Szyprowski
I would also consider sending it to stable.
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index b1838ab..40c330f 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -147,8 +147,9 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
long size,
* No need to sync to the device, this will happen later when the
* prepare() memop is called.
*/
- if (dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->nents,
-buf->dma_dir, ) == 0)
+ sgt->nents = dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
+ buf->dma_dir, );
+ if (!sgt->nents)
goto fail_map;
buf->handler.refcount = >refcount;
@@ -187,7 +188,7 @@ static void vb2_dma_sg_put(void *buf_priv)
dma_set_attr(DMA_ATTR_SKIP_CPU_SYNC, );
dprintk(1, "%s: Freeing buffer of %d pages\n", __func__,
buf->num_pages);
- dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->nents,
+ dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
buf->dma_dir, );
if (buf->vaddr)
vm_unmap_ram(buf->vaddr, buf->num_pages);
@@ -314,9 +315,11 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
unsigned long vaddr,
* No need to sync to the device, this will happen later when the
* prepare() memop is called.
*/
- if (dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->nents,
-buf->dma_dir, ) == 0)
+ sgt->nents = dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
+ buf->dma_dir, );
+ if (!sgt->nents)
goto userptr_fail_map;
+
return buf;
userptr_fail_map:
@@ -351,7 +354,8 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
dprintk(1, "%s: Releasing userspace buffer of %d pages\n",
__func__, buf->num_pages);
- dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir,
);
+ dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir,
+ );
if (buf->vaddr)
vm_unmap_ram(buf->vaddr, buf->num_pages);
sg_free_table(buf->dma_sgt);
@@ -502,7 +506,6 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
/* stealing dmabuf mutex to serialize map/unmap operations */
struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- int ret;
mutex_lock(lock);
@@ -521,8 +524,9 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
}
/* mapping to the client with new direction */
- ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dma_dir);
- if (ret <= 0) {
+ sgt->nents = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
+ dma_dir);
+ if (!sgt->nents) {
pr_err("failed to map scatterlist\n");
mutex_unlock(lock);
return ERR_PTR(-EIO);
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
--
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] media/videobuf2-dma-vmalloc: Save output from dma_map_sg
Hello,
On 2015-02-11 11:33, Ricardo Ribalda Delgado wrote:
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
Signed-off-by: Ricardo Ribalda Delgado
Reviewed-by: Marek Szyprowski
---
drivers/media/v4l2-core/videobuf2-vmalloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index bcde885..f92bc9e 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -287,7 +287,6 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
/* stealing dmabuf mutex to serialize map/unmap operations */
struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- int ret;
mutex_lock(lock);
@@ -306,8 +305,9 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
}
/* mapping to the client with new direction */
- ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dma_dir);
- if (ret <= 0) {
+ sgt->nents = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
+ dma_dir);
+ if (!sgt->nents) {
pr_err("failed to map scatterlist\n");
mutex_unlock(lock);
return ERR_PTR(-EIO);
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
--
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] pcmcia: Use setup_timer and mod_timer
This patch introduces the use of functions setup_timer
and mod_timer.
This is done using Coccinelle and semantic patch used
for this as follows:
//
@@
expression x,y,z,a,b;
@@
-init_timer ();
+setup_timer (, y, z);
+mod_timer (, b);
-x.function = y;
-x.data = z;
-x.expires = b;
-add_timer();
//
Signed-off-by: Vaishali Thakkar
---
drivers/pcmcia/pd6729.c | 8 +++-
drivers/pcmcia/yenta_socket.c | 8 +++-
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/pcmcia/pd6729.c b/drivers/pcmcia/pd6729.c
index 34ace48..0f70b4d 100644
--- a/drivers/pcmcia/pd6729.c
+++ b/drivers/pcmcia/pd6729.c
@@ -707,11 +707,9 @@ static int pd6729_pci_probe(struct pci_dev *dev,
}
} else {
/* poll Card status change */
- init_timer(>poll_timer);
- socket->poll_timer.function = pd6729_interrupt_wrapper;
- socket->poll_timer.data = (unsigned long)socket;
- socket->poll_timer.expires = jiffies + HZ;
- add_timer(>poll_timer);
+ setup_timer(>poll_timer, pd6729_interrupt_wrapper,
+ (unsigned long)socket);
+ mod_timer(>poll_timer, jiffies + HZ);
}
for (i = 0; i < MAX_SOCKETS; i++) {
diff --git a/drivers/pcmcia/yenta_socket.c b/drivers/pcmcia/yenta_socket.c
index 8a23ccb..965bd84 100644
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -1236,11 +1236,9 @@ static int yenta_probe(struct pci_dev *dev, const struct
pci_device_id *id)
if (!socket->cb_irq || request_irq(socket->cb_irq, yenta_interrupt,
IRQF_SHARED, "yenta", socket)) {
/* No IRQ or request_irq failed. Poll */
socket->cb_irq = 0; /* But zero is a valid IRQ number. */
- init_timer(>poll_timer);
- socket->poll_timer.function = yenta_interrupt_wrapper;
- socket->poll_timer.data = (unsigned long)socket;
- socket->poll_timer.expires = jiffies + HZ;
- add_timer(>poll_timer);
+ setup_timer(>poll_timer, yenta_interrupt_wrapper,
+ (unsigned long)socket);
+ mod_timer(>poll_timer, jiffies + HZ);
dev_printk(KERN_INFO, >dev,
"no PCI IRQ, CardBus support disabled for this "
"socket.\n");
--
1.9.1
--
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/
bq2415x_charger, bq27x00_battery.c: comment cleanups
Cleanup comments for bq2415x_charger, bq27x00_battery.c.
Signed-off-by: Pavel Machek
diff --git a/drivers/power/bq2415x_charger.c b/drivers/power/bq2415x_charger.c
index 1f49986..2a226ca 100644
--- a/drivers/power/bq2415x_charger.c
+++ b/drivers/power/bq2415x_charger.c
@@ -13,12 +13,6 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
- */
-
-/*
* Datasheets:
* http://www.ti.com/product/bq24150
* http://www.ti.com/product/bq24150a
@@ -173,7 +167,7 @@ struct bq2415x_device {
struct power_supply *notify_psy;
struct notifier_block nb;
enum bq2415x_mode reported_mode;/* mode reported by hook function */
- enum bq2415x_mode mode; /* current configured mode */
+ enum bq2415x_mode mode; /* currently configured mode */
enum bq2415x_chip chip;
const char *timer_error;
char *model;
diff --git a/drivers/power/bq27x00_battery.c b/drivers/power/bq27x00_battery.c
index a78ac20..6be9f3c 100644
--- a/drivers/power/bq27x00_battery.c
+++ b/drivers/power/bq27x00_battery.c
@@ -16,9 +16,6 @@
* IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*
- */
-
-/*
* Datasheets:
* http://focus.ti.com/docs/prod/folders/print/bq27000.html
* http://focus.ti.com/docs/prod/folders/print/bq27500.html
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] time, ntp: Do not update time_state in middle of leap second
On 02/10/2015 06:47 PM, John Stultz wrote: > On Sun, Feb 8, 2015 at 2:29 AM, Prarit Bhargava wrote: >> During leap second insertion testing it was noticed that a small window >> exists where the time_state could be reset such that >> time_state = TIME_OK, which then causes the leap second to not occur, or >> causes the entire leap second state machine to fail. > > > I think this description is fairly opaque, and probably needs the > specific example of the state change transitions that motivates this > patch. > >> While this is highly unlikely to ever happen in the real world it is >> still something we should protect against, as breaking the state machine >> is obviously bad. > > In this case it was a test-case bug where uninitialized data being > passed to adjtimex (when the test intended to only read the time > state) was causing an unexpected state change transition. So its not > immediately obvious that resetting the state machine when the root > called adjtimex is invalid, so it would be good to make this more > clear and explicit (ie: show the expected state transitions and the > command that caused the strange transition you saw). > > Sorry for the slow response here, I've been on the fence as to if this > is the right thing or not, and have needed to get some time to stare > at this a bit more to see if I can convince myself its the right > thing, so improving the commit message might make it more obvious to > me and others. :) Will do :) I'll write up a proper and detailed description. My bad. P. > > thanks > -john > -- 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 1/2] dma: pl330: improve pl330_tx_status() function
On 02/11/2015 01:23 AM, Vinod Koul wrote:
> On Wed, Dec 10, 2014 at 11:55:17AM +0100, Robert Baldyga wrote:
>> This patch adds possibility to read residue of DMA transfer. It's useful
>> when we want to know how many bytes have been transferred before we
>> terminate channel. It can take place, for example, on timeout interrupt.
>>
>> Signed-off-by: Lukasz Czerwinski
>> Signed-off-by: Robert Baldyga
>> ---
>> drivers/dma/pl330.c | 68
>> +++--
>> 1 file changed, 66 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
>> index bdf40b5..2f4d561 100644
>> --- a/drivers/dma/pl330.c
>> +++ b/drivers/dma/pl330.c
>> @@ -504,6 +504,9 @@ struct dma_pl330_desc {
>>
>> enum desc_status status;
>>
>> +int bytes_requested;
>> +bool last;
>> +
>> /* The channel which currently holds this desc */
>> struct dma_pl330_chan *pchan;
>>
>> @@ -2182,11 +2185,68 @@ static void pl330_free_chan_resources(struct
>> dma_chan *chan)
>> pm_runtime_put_autosuspend(pch->dmac->ddma.dev);
>> }
>>
>> +int pl330_get_current_xferred_count(struct dma_pl330_chan *pch,
>> +struct dma_pl330_desc *desc)
>> +{
>> +struct pl330_thread *thrd = pch->thread;
>> +struct pl330_dmac *pl330 = pch->dmac;
>> +void __iomem *regs = thrd->dmac->base;
>> +u32 val, addr;
>> +
>> +pm_runtime_get_sync(pl330->ddma.dev);
>> +val = addr = 0;
>> +if (desc->rqcfg.src_inc) {
>> +val = readl(regs + SA(thrd->id));
>> +addr = desc->px.src_addr;
>> +} else {
>> +val = readl(regs + DA(thrd->id));
>> +addr = desc->px.dst_addr;
>> +}
>> +pm_runtime_mark_last_busy(pch->dmac->ddma.dev);
>> +pm_runtime_put_autosuspend(pl330->ddma.dev);
>> +return val - addr;
>> +}
>> +
>> static enum dma_status
>> pl330_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
>> struct dma_tx_state *txstate)
>> {
>> -return dma_cookie_status(chan, cookie, txstate);
>> +enum dma_status ret;
>> +unsigned long flags;
>> +struct dma_pl330_desc *desc, *running = NULL;
>> +struct dma_pl330_chan *pch = to_pchan(chan);
>> +unsigned int transferred, residual = 0;
>> +
>> +spin_lock_irqsave(>lock, flags);
> You want to check the dma_cookie_status here first and then based on status
> go into residue calcaultion, that too only when the txstate is NON null.
>
Ok, I will send v4.
Thanks,
Robert Baldyga
--
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 2/6] staging: rtl8188eu: hal: removed code indent error
On Wed, Feb 11, 2015 at 01:40:37AM -0800, Joe Perches wrote: > On Wed, 2015-02-11 at 11:33 +0300, Dan Carpenter wrote: > > You can't fight checkpatch.pl. > > Sure you can, Ignore it whenever appropriate. People will just keep sending patches until something gets merged. It's rude to ignore patches and it's useless because people will just send another email asking you "have you received my patch yet?". It just creates a bigger fight. Applying mediocre checkpatch cleanups takes less time and energy than constantly fighting. It's easiest to not fight over stupid stuff and just apply the patches. Plus it makes the patch senders happy and that creates a happier community. regards, dan carpenter -- 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: [RFC PATCH 8/9] livepatch: allow patch modules to be removed
On 02/10/2015, 08:57 PM, Josh Poimboeuf wrote:
> On Tue, Feb 10, 2015 at 08:02:34PM +0100, Jiri Slaby wrote:
>> On 02/09/2015, 06:31 PM, Josh Poimboeuf wrote:
>>> --- a/kernel/livepatch/core.c
>>> +++ b/kernel/livepatch/core.c
>> ...
>>> @@ -497,10 +500,6 @@ static struct attribute *klp_patch_attrs[] = {
>>>
>>> static void klp_kobj_release_patch(struct kobject *kobj)
>>> {
>>> - /*
>>> -* Once we have a consistency model we'll need to module_put() the
>>> -* patch module here. See klp_register_patch() for more details.
>>> -*/
>>
>> I deliberately let you write the note in there :). What happens when I
>> leave some attribute in /sys open and you remove the module in the meantime?
>
> You're right, as was I the first time :-)
>
> The only problem is that it would be nice if we could call
> klp_unregister_patch() from the patch module's exit function, so that
> doing an rmmod on the patch module unregisters it. But if we put
> module_put() in the patch release function, then we have a circular
> dependency and we could never rmmod it.
>
> How about instead we do a klp_is_patch_registered() at the beginning of
> all the attribute accessor functions? It's kind of ugly, but I can't
> think of a better idea at the moment.
Ugh, no :). You even have the kobject proper in the module which would
be gone.
However we can take inspiration in kgraft. I introduced a completion
there and wait for it in rmmod. This completion is made complete in
kobject's release. See:
https://git.kernel.org/cgit/linux/kernel/git/jirislaby/kgraft.git/tree/kernel/kgraft_files.c?h=kgraft#n30
https://git.kernel.org/cgit/linux/kernel/git/jirislaby/kgraft.git/tree/kernel/kgraft_files.c?h=kgraft#n138
This should IMO work here too.
regards,
--
js
suse labs
--
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] pcmcia: Use setup_timer
This patch introduces the use of function setup_timer.
This is done using Coccinelle and semantic patch used is
as follows:
@@
expression x,y,z;
@@
- init_timer ();
+ setup_timer (, y, z);
- x.function = y;
- x.data = z;
Signed-off-by: Vaishali Thakkar
---
drivers/pcmcia/omap_cf.c| 4 +---
drivers/pcmcia/soc_common.c | 5 ++---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/pcmcia/omap_cf.c b/drivers/pcmcia/omap_cf.c
index 8170102..4e2f501 100644
--- a/drivers/pcmcia/omap_cf.c
+++ b/drivers/pcmcia/omap_cf.c
@@ -220,9 +220,7 @@ static int __init omap_cf_probe(struct platform_device
*pdev)
cf = kzalloc(sizeof *cf, GFP_KERNEL);
if (!cf)
return -ENOMEM;
- init_timer(>timer);
- cf->timer.function = omap_cf_timer;
- cf->timer.data = (unsigned long) cf;
+ setup_timer(>timer, omap_cf_timer, (unsigned long)cf);
cf->pdev = pdev;
platform_set_drvdata(pdev, cf);
diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c
index 933f465..eed5e9c 100644
--- a/drivers/pcmcia/soc_common.c
+++ b/drivers/pcmcia/soc_common.c
@@ -726,9 +726,8 @@ int soc_pcmcia_add_one(struct soc_pcmcia_socket *skt)
{
int ret;
- init_timer(>poll_timer);
- skt->poll_timer.function = soc_common_pcmcia_poll_event;
- skt->poll_timer.data = (unsigned long)skt;
+ setup_timer(>poll_timer, soc_common_pcmcia_poll_event,
+ (unsigned long)skt);
skt->poll_timer.expires = jiffies + SOC_PCMCIA_POLL_PERIOD;
ret = request_resource(_resource, >res_skt);
--
1.9.1
--
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/2] dma: pl330: add DMA_PAUSE feature
On 02/11/2015 01:24 AM, Vinod Koul wrote: > On Wed, Dec 10, 2014 at 11:55:18AM +0100, Robert Baldyga wrote: >> DMA_PAUSE command is used for halting DMA transfer on chosen channel. >> It can be useful when we want to safely read residue before terminating >> all requests on channel. Otherwise there can be situation when some data >> is transferred before channel termination but after reading residue, >> which obviously results with data loss. To avoid this situation we can >> pause channel, read residue and then terminate all requests. >> This scenario is common, for example, in serial port drivers. > And where is the resume here? Also this needs rebase > We can't have resume on this hardware. It's in comment. DMA_PAUSE feature is added only to freeze channel state before its termination to allow safe residue read. BTW I was almost sure that you have applied these patches to your tree about two months ago. In mainline kernel there is already samsung serial driver using DMA, which wouldn't work without these changes. Hence it would be great to have my patches applied ASAP. I will send v4 today. Thanks, Robert Baldyga -- 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] x86 spinlock: Fix memory corruption on completing completions
On 02/10/2015 06:56 PM, Oleg Nesterov wrote: On 02/10, Raghavendra K T wrote: On 02/10/2015 06:23 AM, Linus Torvalds wrote: add_smp(>tickets.head, TICKET_LOCK_INC); if (READ_ONCE(lock->tickets.tail) & TICKET_SLOWPATH_FLAG) .. into something like val = xadd((>ticket.head_tail, TICKET_LOCK_INC << TICKET_SHIFT); if (unlikely(val & TICKET_SLOWPATH_FLAG)) ... would be the right thing to do. Somebody should just check that I got that shift right, and that the tail is in the high bytes (head really needs to be high to work, if it's in the low byte(s) the xadd would overflow from head into tail which would be wrong). Unfortunately xadd could result in head overflow as tail is high. The other option was repeated cmpxchg which is bad I believe. Any suggestions? Stupid question... what if we simply move SLOWPATH from .tail to .head? In this case arch_spin_unlock() could do xadd(tickets.head) and check the result It is a good idea. Trying this now. In this case __ticket_check_and_clear_slowpath() really needs to cmpxchg the whole .head_tail. Plus obviously more boring changes. This needs a separate patch even _if_ this can work. Correct, but apart from this, before doing xadd in unlock, we would have to make sure lsb bit is cleared so that we can live with 1 bit overflow to tail which is unused. now either or both of head,tail lsb bit may be set after unlock. -- 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 v2] rtl2832: remove compiler warning
Cleaning up the following compiler warning: rtl2832.c:703:12: warning: 'tmp' may be used uninitialized in this function Even though it could never happen since if rtl2832_rd_demod_reg () doesn't set tmp, this line would never run because we go to err. It is still nice to avoid compiler warnings. Signed-off-by: Luis de Bethencourt --- drivers/media/dvb-frontends/rtl2832.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/rtl2832.c b/drivers/media/dvb-frontends/rtl2832.c index 5d2d8f4..20fa245 100644 --- a/drivers/media/dvb-frontends/rtl2832.c +++ b/drivers/media/dvb-frontends/rtl2832.c @@ -685,7 +685,7 @@ static int rtl2832_read_status(struct dvb_frontend *fe, fe_status_t *status) struct rtl2832_dev *dev = fe->demodulator_priv; struct i2c_client *client = dev->client; int ret; - u32 tmp; + u32 uninitialized_var(tmp); dev_dbg(>dev, "\n"); -- 2.1.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 3/3] stmmac: Add AXI burst length support to platform device.
On Tue, Feb 10, 2015 at 11:48:37AM +, Mark Rutland wrote: > > On Mon, Feb 09, 2015 at 12:04:43PM +, Mark Rutland wrote: > > > On Sat, Feb 07, 2015 at 05:07:16AM +, Chen Baozi wrote: > > > > The AXI Bus Mode Register controls the AXI master behavior. It is mainly > > > > used to control the burst splitting and the number of outstanding > > > > requests. > > > > This register is present and valid only in GMAC-AXI configuration. The > > > > old > > > > driver only supports this feature on PCI devices. This patch adds an > > > > 'snps,apl' properties in DT to enable it on platform devices. > > > > > > > > Signed-off-by: Chen Baozi > > > > --- > > > > Documentation/devicetree/bindings/net/stmmac.txt | 1 + > > > > drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 + > > > > 2 files changed, 2 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/net/stmmac.txt > > > > b/Documentation/devicetree/bindings/net/stmmac.txt > > > > index c41afd9..8f3c834 100644 > > > > --- a/Documentation/devicetree/bindings/net/stmmac.txt > > > > +++ b/Documentation/devicetree/bindings/net/stmmac.txt > > > > @@ -43,6 +43,7 @@ Optional properties: > > > >available this clock is used for programming the Timestamp Addend > > > > Register. > > > >If not passed then the system clock will be used and this is fine on > > > > some > > > >platforms. > > > > +- snps,abl: AXI Burst Length > > > > > > This is not a good name (though I see it follows "snps,pbl", which is > > > also not a good name)... > > > > Any idea for a better name? > > Perhaps snps,axi-burst-length ? > > > > Why does this need to be in the DT? Is this required for correctness? Or > > > performance? > > > > This is required for correctness. Otherwise, the driver would write > > '0' to the register by default, which makes the driver not work. > > What does that mean at the HW level? If that won't work in all cases > why does the driver do that? According to the manual, this is used to select the burst length on AXI master interface. The register is optional and valid only in GMAC-AXI configuration. IMHO, not all cases require the driver to set this register. So I just put it in the 'optional properties', in case some devices depend on that. Cheers, Baozi. -- 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 v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
On Wed, Feb 11, 2015 at 08:53:39AM +, Boris Brezillon wrote:
> Hi Mark,
>
> On Tue, 10 Feb 2015 20:48:36 +
> Mark Rutland wrote:
>
> > On Tue, Feb 10, 2015 at 03:52:01PM +, Boris Brezillon wrote:
> > > Hi Mark,
> > >
> > > On Tue, 10 Feb 2015 15:36:28 +
> > > Mark Rutland wrote:
> > >
> > > > Hi Boris,
> > > >
> > > > On Thu, Jan 29, 2015 at 10:33:38AM +, Boris Brezillon wrote:
> > > > > Add documentation for the virtual irq demuxer.
> > > > >
> > > > > Signed-off-by: Boris Brezillon
> > > > > Acked-by: Nicolas Ferre
> > > > > ---
> > > > > .../bindings/interrupt-controller/dumb-demux.txt | 41
> > > > > ++
> > > > > 1 file changed, 41 insertions(+)
> > > > > create mode 100644
> > > > > Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
> > > > >
> > > > > b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
> > > > > new file mode 100644
> > > > > index 000..b9a7830
> > > > > --- /dev/null
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
> > > > > @@ -0,0 +1,41 @@
> > > > > +* Virtual Interrupt Demultiplexer
> > > > > +
> > > > > +This virtual demultiplexer simply forward all incoming interrupts to
> > > > > its
> > > > > +enabled/unmasked children.
> > > > > +It is only intended to be used by hardware that do not provide a
> > > > > proper way
> > > > > +to demultiplex a source interrupt, and thus have to wake all their
> > > > > children
> > > > > +up so that they can possibly handle the interrupt (if needed).
> > > > > +This can be seen as an alternative to shared interrupts when at
> > > > > least one
> > > > > +of the interrupt children is a timer (and require the irq to stay
> > > > > enabled
> > > > > +on suspend) while others are not. This will prevent calling irq
> > > > > handlers of
> > > > > +non timer devices while they are suspended.
> > > >
> > > > This sounds like a DT-workaround for a Linux implementation problem, and
> > > > I don't think this the right way to solve your problem.
> > >
> > > I understand your concern, but why are you answering while I asked for
> > > DT maintainers reviews for several days (if not several weeks).
> > >
> > > >
> > > > Why does this have to be in DT at all? Why can we not fix the core to
> > > > handle these details?
> > >
> > > We already discussed that with Rob and Thomas, and hiding such a
> > > demuxer chip is not an easy task.
> > > I'm open to any suggestion to do that, though I'd like you (I mean DT
> > > guys) to provide a working implementation (or at least a viable concept)
> > > that would silently demultiplex an irq.
> > >
> > > >
> > > > I am very much not keen on this binding.
> > >
> > > Yes, but do you have anything else to propose.
> > > We're experiencing this warning for 2 releases now, and this is time to
> > > find a solution (even if it's not a perfect one).
> >
> > Thoughts on the patch below?
>
> That's pretty much what I proposed in my first attempt to solve this
> problem [1] (except for a few things commented below).
> Anyway, Thomas suggested to go for the "dumb/virt irq demultiplexer"
> approach instead.
There is one fundamental difference in that this patch does not require
drivers to be updated (the new flag is only used internally). Which
avoids having to patch every single driver that could possibly be used
in combination with one wanting interrupts during suspend.
Any used which did not explicitly request with IRQF_NO_SUSPEND will not
receive interrupts during suspend.
[...]
> > +static irqreturn_t __handle_irq_event_percpu(unsigned int irq, struct
> > irqaction *action)
> > +{
> > + /*
> > +* During suspend we must not call potentially unsafe irq handlers.
> > +* See suspend_suspendable_actions.
> > +*/
> > + if (unlikely(action->flags & IRQF_NO_ACTION))
> > + return IRQ_NONE;
>
> Thomas was trying to avoid any new conditional code in the interrupt
> handling path, that's why I added a suspended_action list in my
> proposal.
> Even if your 'unlikely' statement make things better I'm pretty sure it
> adds some latency.
I can see that we don't want to add more code here to keep things
clean/pure, but I find it hard to believe that a single bit test and
branch (for data that should be hot in the cache) are going to add
measurable latency to a path that does pointer chasing to get to the
irqaction in the first place. I could be wrong though, and I'm happy to
benchmark.
It would be possible to go for your list shuffling approach here while
still keeping the flag internal and all the logic hidden away in
kernel/irq/pm.c. I wasn't sure how actions could be manipulated during
suspend, which made me wary of moving them to a separate list.
> > + return action->handler(irq, action->dev_id);
> > +}
> > +
> > irqreturn_t
Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote: > Hello, > > On 2015-01-27 09:25, Sumit Semwal wrote: > >Add some helpers to share the constraints of devices while attaching > >to the dmabuf buffer. > > > >At each attach, the constraints are calculated based on the following: > >- max_segment_size, max_segment_count, segment_boundary_mask from > >device_dma_parameters. > > > >In case the attaching device's constraints don't match up, attach() fails. > > > >At detach, the constraints are recalculated based on the remaining > >attached devices. > > > >Two helpers are added: > >- dma_buf_get_constraints - which gives the current constraints as calculated > > during each attach on the buffer till the time, > >- dma_buf_recalc_constraints - which recalculates the constraints for all > > currently attached devices for the 'paranoid' ones amongst us. > > > >The idea of this patch is largely taken from Rob Clark's RFC at > >https://lkml.org/lkml/2012/7/19/285, and the comments received on it. > > > >Cc: Rob Clark > >Signed-off-by: Sumit Semwal > > The code looks okay, although it will probably will work well only with > typical cases like 'contiguous memory needed' or 'no constraints at all' > (iommu). Which is a damn good reason to NAK it - by that admission, it's a half-baked idea. If all we want to know is whether the importer can accept only contiguous memory or not, make a flag to do that, and allow the exporter to test this flag. Don't over-engineer this to make it _seem_ like it can do something that it actually totally fails with. As I've already pointed out, there's a major problem if you have already had a less restrictive attachment which has an active mapping, and a new more restrictive attachment comes along later. It seems from Rob's descriptions that we also need another flag in the importer to indicate whether it wants to have a valid struct page in the scatter list, or whether it (correctly) uses the DMA accessors on the scatter list - so that exporters can reject importers which are buggy. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 2/2 --resend] perf: update userspace page info for software event
On Thu, Feb 05, 2015 at 03:55:32PM -0800, Shaohua Li wrote:
> For hardware event, the userspace page of the event gets updated in
> context switch, so if we read time in the page, we get updated info. For
> software event, this is missed currently. This patch makes the behavior
> consistency.
>
> With this patch, we can implement clock_gettime(THREAD_CPUTIME) with
> PERF_COUNT_SW_DUMMY in userspace as suggested by Andy and Peter. Code
> likes this:
>
> if (pc->cap_user_time) {
> do {
> seq = pc->lock;
> barrier();
>
> running = pc->time_running;
> cyc = rdtsc();
> time_mult = pc->time_mult;
> time_shift = pc->time_shift;
> time_offset = pc->time_offset;
>
> barrier();
> } while (pc->lock != seq);
>
> quot = (cyc >> time_shift);
> rem = cyc & ((1 << time_shift) - 1);
> delta = time_offset + quot * time_mult +
> ((rem * time_mult) >> time_shift);
You could maybe use:
static inline u64 mul_u64_u32_shr(u64 a, u32 mul, unsigned int shift)
{
return (u64)(((unsigned __int128)a * mul) >> shift);
}
And save yourself a mult instruction if you have suitable (64bit)
hardware and a recent GCC.
> running += delta;
> return running;
> }
>
Thanks for poking me. Applied.
--
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 v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
On Wed, Feb 11, 2015 at 09:11:59AM +, Peter Zijlstra wrote: > On Tue, Feb 10, 2015 at 08:48:36PM +, Mark Rutland wrote: > > From f390ccbb31f06efee49b4469943c8d85d963bfb5 Mon Sep 17 00:00:00 2001 > > From: Mark Rutland > > Date: Tue, 10 Feb 2015 20:14:33 + > > Subject: [PATCH] genirq: allow mixed IRQF_NO_SUSPEND requests > > > > In some cases a physical IRQ line may be shared between devices from > > which we expect interrupts during suspend (e.g. timers) and those we do > > not (e.g. anything we cut the power to). Where a driver did not request > > the interrupt with IRQF_NO_SUSPEND, it's unlikely that it can handle > > being called during suspend, and it may bring down the system. > > > > This patch adds logic to automatically mark the irqactions for these > > potentially unsafe handlers as disabled during suspend, leaving actions > > with IRQF_NO_SUSPEND enabled. If an interrupt is raised on a shared line > > during suspend, only the handlers requested with IRQF_NO_SUSPEND will be > > called. The handlers requested without IRQF_NO_SUSPEND will be skipped > > as if they had immediately returned IRQF_NONE. > > > > Cc: Boris Brezillon > > Cc: Jason Cooper > > Cc: Nicolas Ferre > > Cc: Peter Zijlstra > > Cc: Rafael J. Wysocki > > Cc: Thomas Gleixner > > Signed-off-by: Mark Rutland > > Aw gawd.. not that again. I agree this isn't pretty, but at least it doesn't require the HW description to know about Linux internals, and it can work for !DT systems. I'm really not happy with placing Linux implementation details into DTBs. > So Rafael and tglx went over this a few months ago I think: > > lkml.kernel.org/r/26580319.ozp7jvj...@vostro.rjw.lan > > is the last series I could find. Maybe Rafael can summarize? I can't get at any commentary from that link, unfortunately. Rafael? Thanks, Mark. -- 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 5/5] virtio: don't require a config space on the console device.
On (Mon) 09 Feb 2015 [10:26:29], Rusty Russell wrote:
> virtio: don't require a config space on the console device.
>
> Strictly, it's only needed when we have features (size or multiport).
>
> Signed-off-by: Rusty Russell
Reviewed-by: Amit Shah
> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> index 26afb56a8073..fae2dbbf5745 100644
> --- a/drivers/char/virtio_console.c
> +++ b/drivers/char/virtio_console.c
> @@ -1986,7 +1986,10 @@ static int virtcons_probe(struct virtio_device *vdev)
> bool multiport;
> bool early = early_put_chars != NULL;
>
> - if (!vdev->config->get) {
> + /* We only need a config space if features are offered */
> + if (!vdev->config->get &&
> + (virtio_has_feature(vdev, VIRTIO_CONSOLE_F_SIZE)
> + || virtio_has_feature(vdev, VIRTIO_CONSOLE_F_MULTIPORT))) {
> dev_err(>dev, "%s failure: config access disabled\n",
> __func__);
> return -EINVAL;
Amit
--
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] rtl2832: remove compiler warning
On Tue, Feb 10, 2015 at 09:35:52PM -0200, Mauro Carvalho Chehab wrote: > Em Tue, 10 Feb 2015 12:57:24 +0200 > Antti Palosaari escreveu: > > > On 02/09/2015 12:44 AM, Luis de Bethencourt wrote: > > > Cleaning the following compiler warning: > > > rtl2832.c:703:12: warning: 'tmp' may be used uninitialized in this > > > function > > > > > > Even though it could never happen since if rtl2832_rd_demod_reg () > > > doesn't set > > > tmp, this line would never run because we go to err. It is still nice to > > > avoid > > > compiler warnings. > > > > > > Signed-off-by: Luis de Bethencourt > > > --- > > > drivers/media/dvb-frontends/rtl2832.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/media/dvb-frontends/rtl2832.c > > > b/drivers/media/dvb-frontends/rtl2832.c > > > index 5d2d8f4..ad36d1c 100644 > > > --- a/drivers/media/dvb-frontends/rtl2832.c > > > +++ b/drivers/media/dvb-frontends/rtl2832.c > > > @@ -685,7 +685,7 @@ static int rtl2832_read_status(struct dvb_frontend > > > *fe, fe_status_t *status) > > > struct rtl2832_dev *dev = fe->demodulator_priv; > > > struct i2c_client *client = dev->client; > > > int ret; > > > - u32 tmp; > > > + u32 tmp = 0; > > > > > > dev_dbg(>dev, "\n"); > > > > I looked the code and I cannot see how it could used as uninitialized. > > Dunno how it could be fixed properly. > > > > Also, I think idiom to say compiler that variable could be uninitialized > > is to store its own value. But I am fine with zero initialization too. > > > > u32 tmp = tmp; > > Actually, the right way is to declare it as: > > u32 uninitialized_var(tmp) > > The syntax to suppress compiler warnings depends on the compiler: > > include/linux/compiler-clang.h:#define uninitialized_var(x) x = *(&(x)) > include/linux/compiler-gcc.h:#define uninitialized_var(x) x = x > > Also, using uninitialized_var() better documents it. > > Regards, > Mauro Hi Mauro, That is a way more elegant solution. Great! I will check out that compiler-clang header file, it's interesting. I just sent a revised patch using this :) Thanks, Luis -- 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] Added Pids for Actisense Usb Devices
From: Mark Glover
Signed-off-by: Mark Glover
---
drivers/usb/serial/ftdi_sio.c | 17 +
drivers/usb/serial/ftdi_sio_ids.h | 21 +
2 files changed, 38 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 1ebb351..651dc1b 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -978,6 +978,23 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE_INTERFACE_NUMBER(INFINEON_VID, INFINEON_TRIBOARD_PID, 1) },
/* GE Healthcare devices */
{ USB_DEVICE(GE_HEALTHCARE_VID, GE_HEALTHCARE_NEMO_TRACKER_PID) },
+ /* Active Research (Actisense) devices */
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NDC_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_USG_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NGT_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_NGW_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AC_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AD_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AE_PID) },
+ { USB_DEVICE(FTDI_VID, ACTISENSE_D9AF_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEAGAUGE_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASWITCH_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_NMEA2000_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ETHERNET_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_WIFI_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_DISPLAY_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_LITE_PID) },
+ { USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ANALOG_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index e52409c..87d9ed7 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1438,3 +1438,23 @@
*/
#define GE_HEALTHCARE_VID 0x1901
#define GE_HEALTHCARE_NEMO_TRACKER_PID 0x0015
+
+/*
+ * Active Research (Actisense) devices
+ */
+#define ACTISENSE_NDC_PID 0xD9A8 /* NDC USB Serial Adapter */
+#define ACTISENSE_USG_PID 0xD9A9 /* USG USB Serial Adapter */
+#define ACTISENSE_NGT_PID 0xD9AA /* NGT NMEA2000 Interface */
+#define ACTISENSE_NGW_PID 0xD9AB /* NGW NMEA2000 Gateway */
+#define ACTISENSE_D9AC_PID 0xD9AC /* Actisense Reserved */
+#define ACTISENSE_D9AD_PID 0xD9AD /* Actisense Reserved */
+#define ACTISENSE_D9AE_PID 0xD9AE /* Actisense Reserved */
+#define ACTISENSE_D9AF_PID 0xD9AF /* Actisense Reserved */
+#define CHETCO_SEAGAUGE_PID0xA548 /* SeaGauge USB Adapter */
+#define CHETCO_SEASWITCH_PID 0xA549 /* SeaSwitch USB Adapter */
+#define CHETCO_SEASMART_NMEA2000_PID 0xA54A /* SeaSmart NMEA2000 Gateway */
+#define CHETCO_SEASMART_ETHERNET_PID 0xA54B /* SeaSmart Ethernet Gateway */
+#define CHETCO_SEASMART_WIFI_PID 0xA5AC /* SeaSmart Wifi Gateway */
+#define CHETCO_SEASMART_DISPLAY_PID0xA5AD /* SeaSmart NMEA2000 Display */
+#define CHETCO_SEASMART_LITE_PID 0xA5AE /* SeaSmart Lite USB Adapter */
+#define CHETCO_SEASMART_ANALOG_PID 0xA5AF /* SeaSmart Analog Adapter */
--
1.7.9.5
--
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] Add LTC2941/LTC2943 Battery Gauge Driver
On 22-01-15 03:24, Sebastian Reichel wrote: Hi, On Tue, Oct 28, 2014 at 08:05:12AM +0100, Mike Looijmans wrote: Both the LTC2941 and LTC2943 measure battery capacity. The LTC2943 is compatible with the LTC2941, it adds voltage and temperature monitoring, and uses a slightly different conversion formula for the charge counter. To avoid confusion with e.g. the LTC2945, the driver is called LTC2941 instead of LTC294X. Applied with .owner field removed. -- Sebastian Hello, We found a bug in the LTC2941 driver (typo, it says "58" in the formula which should be "85") just yesterday. I couldn't find it in mainline yet, I'll post a patch to fix it. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Visit us at Embedded World 2015 Nuernberg, 24.02.2015 till 26.02.2015, Hall 1, stand number 136. https://www.embedded-world.de/de/ausstellerprodukte/?focus=edb3exhibitor=14017667=embwld15=topic -- 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] compat: Fix endian issue in union sigval
On 2015/2/10 20:27, Catalin Marinas wrote:
> cc'ing linux-arch as well.
>
> On Tue, Feb 10, 2015 at 10:10:11AM +, Zhang Jian(Bamvor) wrote:
>> In 64bit architecture, sigval_int is the high 32bit of sigval_ptr in
>> big endian kernel compare with low 32bit of sigval_ptr in little
>> endian kernel. reference:
>>
>> typedef union sigval {
>> int sival_int;
>> void *sival_ptr;
>> } sigval_t;
>>
>> During compat_mq_notify or compat_timer_create, kernel get sigval
>> from user space by reading sigval.sival_int. This is correct in 32 bit
>> kernel and in 64bit little endian kernel. And It is wrong in 64bit big
>> endian kernel:
>> It get the high 32bit of sigval_ptr and put it to low 32bit of
>> sigval_ptr. And the high 32bit sigval_ptr in empty in arm 32bit user
>> space struct. So, kernel lost the value of sigval_ptr.
>>
>> The following patch get the sigval_ptr in stead of sigval_int in order
>> to avoid endian issue.
>> Test pass in arm64 big endian and little endian kernel.
>>
>> Signed-off-by: Zhang Jian(Bamvor)
>> ---
>> ipc/compat_mq.c | 7 ++-
>> kernel/compat.c | 6 ++
>> 2 files changed, 4 insertions(+), 9 deletions(-)
>>
>> diff --git a/ipc/compat_mq.c b/ipc/compat_mq.c
>> index ef6f91c..2e07343 100644
>> --- a/ipc/compat_mq.c
>> +++ b/ipc/compat_mq.c
>> @@ -99,11 +99,8 @@ COMPAT_SYSCALL_DEFINE2(mq_notify, mqd_t, mqdes,
>> if (u_notification) {
>> struct sigevent n;
>> p = compat_alloc_user_space(sizeof(*p));
>> -if (get_compat_sigevent(, u_notification))
>> -return -EFAULT;
>> -if (n.sigev_notify == SIGEV_THREAD)
>> -n.sigev_value.sival_ptr =
>> compat_ptr(n.sigev_value.sival_int);
>> -if (copy_to_user(p, , sizeof(*p)))
>> +if (get_compat_sigevent(, u_notification) ||
>> +copy_to_user(p, , sizeof(*p)))
>> return -EFAULT;
>
> The kernel doesn't need to interpret the sival_ptr value, it's something
> to be passed to the notifier function as an argument.
Yeah, this is the reason why I try to fix sival_ptr through
get_compat_sigevent before sys_mq_notify. After this compat wrapper,
sys_mq_notify will put the sival_ptr to nc buffer(file ipc/mqueue.c line 1221
to line 1226):
if (copy_from_user(nc->data,
notification.sigev_value.sival_ptr,
NOTIFY_COOKIE_LEN)) {
ret = -EFAULT;
goto out;
}
/* TODO: add a header? */
skb_put(nc, NOTIFY_COOKIE_LEN);
/* and attach it to the socket */
The original changes is introduced by Alexander Viro
more than ten years ago[1]:
author Alexander Viro 2004-07-13
04:02:57 (GMT)
committer Linus Torvalds2004-07-13 04:02:57
(GMT)
commit 95b5842264ac470a1a3a59d2741bb18adb140c8b (patch)
tree5167f68fae8f3bbc9b3a2d7617d1500356837c16 /ipc/compat_mq.c
parent de54add33621c5b4a1be895c82b7af96fb4dd447 (diff)
[PATCH] sparse: ipc compat annotations and cleanups
ipc compat code switched to compat_alloc_user_space() and annotated.
> For the user's
> convenience, it is a union of an int and ptr. So I think the original
> SIGEV_THREAD check and compat_ptr() conversion here is wrong, it
> shouldn't exist at all (it doesn't exist in compat_sys_timer_create
> either). This hunk looks fine to me.
>
>> }
>> return sys_mq_notify(mqdes, p);
>> diff --git a/kernel/compat.c b/kernel/compat.c
>> index ebb3c36..13a0e5d 100644
>> --- a/kernel/compat.c
>> +++ b/kernel/compat.c
>> @@ -871,16 +871,14 @@ COMPAT_SYSCALL_DEFINE4(clock_nanosleep, clockid_t,
>> which_clock, int, flags,
>> * We currently only need the following fields from the sigevent
>> * structure: sigev_value, sigev_signo, sig_notify and (sometimes
>> * sigev_notify_thread_id). The others are handled in user mode.
>> - * We also assume that copying sigev_value.sival_int is sufficient
>> - * to keep all the bits of sigev_value.sival_ptr intact.
>> */
>> int get_compat_sigevent(struct sigevent *event,
>> const struct compat_sigevent __user *u_event)
>> {
>> memset(event, 0, sizeof(*event));
>> return (!access_ok(VERIFY_READ, u_event, sizeof(*u_event)) ||
>> -__get_user(event->sigev_value.sival_int,
>> -_event->sigev_value.sival_int) ||
>> +__get_user(*(long long*)event->sigev_value.sival_ptr,
should be:
__get_user(event->sigev_value.sival_ptr,
> > + _event->sigev_value.sival_ptr) ||
>
> I don't think this is correct because some (most) architectures use
> sival_int here when copying to user and for a big endian compat they
> would get 0 for sival_int (mips, powerpc).
Sorry, I am lost here. As we mentioned above, sival_ptr and sival_int
is union, so, copy sival_ptr should include sival_int.
>
> I think the correct fix is in the arm64 code:
The following code could fix my issue.
regards
bamvor
> diff --git a/arch/arm64/kernel/signal32.c
Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux wrote: > On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote: >> Hello, >> >> On 2015-01-27 09:25, Sumit Semwal wrote: >> >Add some helpers to share the constraints of devices while attaching >> >to the dmabuf buffer. >> > >> >At each attach, the constraints are calculated based on the following: >> >- max_segment_size, max_segment_count, segment_boundary_mask from >> >device_dma_parameters. >> > >> >In case the attaching device's constraints don't match up, attach() fails. >> > >> >At detach, the constraints are recalculated based on the remaining >> >attached devices. >> > >> >Two helpers are added: >> >- dma_buf_get_constraints - which gives the current constraints as >> >calculated >> > during each attach on the buffer till the time, >> >- dma_buf_recalc_constraints - which recalculates the constraints for all >> > currently attached devices for the 'paranoid' ones amongst us. >> > >> >The idea of this patch is largely taken from Rob Clark's RFC at >> >https://lkml.org/lkml/2012/7/19/285, and the comments received on it. >> > >> >Cc: Rob Clark >> >Signed-off-by: Sumit Semwal >> >> The code looks okay, although it will probably will work well only with >> typical cases like 'contiguous memory needed' or 'no constraints at all' >> (iommu). > > Which is a damn good reason to NAK it - by that admission, it's a half-baked > idea. > > If all we want to know is whether the importer can accept only contiguous > memory or not, make a flag to do that, and allow the exporter to test this > flag. Don't over-engineer this to make it _seem_ like it can do something > that it actually totally fails with. jfyi, I agree with that.. I think the flag is probably the right approach to start with. At the end of the day it *is* still just an in-kernel API (and not something that ends up as userspace ABI) so when we come up with the use case to make it more generic we can. Vs. making it look like something more generic when it isn't really yet. > As I've already pointed out, there's a major problem if you have already > had a less restrictive attachment which has an active mapping, and a new > more restrictive attachment comes along later. > > It seems from Rob's descriptions that we also need another flag in the > importer to indicate whether it wants to have a valid struct page in the > scatter list, or whether it (correctly) uses the DMA accessors on the > scatter list - so that exporters can reject importers which are buggy. to be completely generic, we would really need a way that the device could take over only just the last iommu (in case there were multiple levels of address translation).. I'm not completely sure, but I *think* the other arm gpu's have their own internal mmu for doing context switching, etc, so if there is an additional iommu in front of them they may actually still want to use the normal dma api's. Someone please contradict me if I am wrong. If this ends up being an issue only for msm, then I'm completely ok with the easier option of a less generic solution.. BR, -R > > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net. -- 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] fs: ufs: super.c: remove unnecessary casting of value.
It is not necessary to cast the value returned by kmem_cache_alloc(),
thus it can be deleted.
This issue was detected using Coccinelle.
Signed-off-by: Bas Peters
---
fs/ufs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ufs/super.c b/fs/ufs/super.c
index da73801..1e4fbf7 100644
--- a/fs/ufs/super.c
+++ b/fs/ufs/super.c
@@ -1415,7 +1415,7 @@ static struct kmem_cache * ufs_inode_cachep;
static struct inode *ufs_alloc_inode(struct super_block *sb)
{
struct ufs_inode_info *ei;
- ei = (struct ufs_inode_info *)kmem_cache_alloc(ufs_inode_cachep,
GFP_NOFS);
+ ei = kmem_cache_alloc(ufs_inode_cachep, GFP_NOFS);
if (!ei)
return NULL;
ei->vfs_inode.i_version = 1;
--
2.1.0
--
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/2] afs: Migrate to 64-bit timekeeping
Tina Ruchandani wrote: > This patchset is an attempt to port afs's timekeeping > variables from time_t type to time64_t. AFS uses > get_seconds to store real (wall clock) time in seconds. > The time returned by get_seconds() will overflow on 32-bit systems > in year 2106 and beyond. > This patchset replaces the usage with ktime_get_real_seconds. > Fields that propagate to the inode (mtime_client, mtime_server, > creation) remain untouched, as the inode timestamps are only 32bit. I've applied these to my branch. David -- 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 v2] staging: panel: initialize lcd if lcd enabled
initialiaze lcd parameters only if lcd is enabled.
Signed-off-by: Sudip Mukherjee
---
v2: fix indention of comment
drivers/staging/panel/panel.c | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/panel/panel.c b/drivers/staging/panel/panel.c
index 6ed35b6..31d8608 100644
--- a/drivers/staging/panel/panel.c
+++ b/drivers/staging/panel/panel.c
@@ -2323,25 +2323,6 @@ static int __init panel_init_module(void)
break;
}
- /*
-* Init lcd struct with load-time values to preserve exact current
-* functionality (at least for now).
-*/
- lcd.height = lcd_height;
- lcd.width = lcd_width;
- lcd.bwidth = lcd_bwidth;
- lcd.hwidth = lcd_hwidth;
- lcd.charset = lcd_charset;
- lcd.proto = lcd_proto;
- lcd.pins.e = lcd_e_pin;
- lcd.pins.rs = lcd_rs_pin;
- lcd.pins.rw = lcd_rw_pin;
- lcd.pins.cl = lcd_cl_pin;
- lcd.pins.da = lcd_da_pin;
- lcd.pins.bl = lcd_bl_pin;
-
- /* Leave it for now, just in case */
- lcd.esc_seq.len = -1;
/*
* Overwrite selection with module param values (both keypad and lcd),
@@ -2361,6 +2342,28 @@ static int __init panel_init_module(void)
lcd.enabled = (selected_lcd_type > 0);
+ if (lcd.enabled) {
+ /*
+* Init lcd struct with load-time values to preserve exact
+* current functionality (at least for now).
+*/
+ lcd.height = lcd_height;
+ lcd.width = lcd_width;
+ lcd.bwidth = lcd_bwidth;
+ lcd.hwidth = lcd_hwidth;
+ lcd.charset = lcd_charset;
+ lcd.proto = lcd_proto;
+ lcd.pins.e = lcd_e_pin;
+ lcd.pins.rs = lcd_rs_pin;
+ lcd.pins.rw = lcd_rw_pin;
+ lcd.pins.cl = lcd_cl_pin;
+ lcd.pins.da = lcd_da_pin;
+ lcd.pins.bl = lcd_bl_pin;
+
+ /* Leave it for now, just in case */
+ lcd.esc_seq.len = -1;
+ }
+
switch (selected_keypad_type) {
case KEYPAD_TYPE_OLD:
keypad_profile = old_keypad_profile;
--
1.8.1.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 v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Thu, Jan 29, 2015 at 03:58:42AM +, Suman Anna wrote:
> On 01/22/2015 12:56 PM, Mark Rutland wrote:
> > On Wed, Jan 21, 2015 at 05:56:37PM +, Suman Anna wrote:
> >> On 01/21/2015 06:41 AM, Ohad Ben-Cohen wrote:
> >>> On Tue, Jan 20, 2015 at 8:05 PM, Tony Lindgren wrote:
> How about default to Linux id space and allow overriding that with
> a module param option if needed?
> >>>
> >>> I'm not sure I'm following.
> >>>
> >>> If the main point of contention is the base_id field, I'm also fine
> >>> with removing it entirely, as I'm not aware of any actual user for it
> >>> (Suman please confirm?).
> >>
> >> Yeah, well the current implementations that I am aware of only have a
> >> single bank, so all of them would be using a value of 0. I am yet to see
> >> a platform with multiple instances where the property really makes a
> >> difference. v7 has the property mandatory, so all the implementations
> >> would need to define this value even if it is 0.
> >>
> >> regards
> >> Suman
> >>
> >>>
> >>> Mark? Rob? Will you accept Suman's patches if the base_id field is
> >>> removed?
> >
> > My concern is that the mapping of hwspinlock IDs doesn't seem to be
> > explicit in the DT on a per-context basis, which is what I'd expect.
> >
> > e.g.
> >
> > lck: hwspinlock-device@f00 {
> > ...
> > #hwlock-cells = <1>;
> > };
> >
> > some-other-os-interface {
> > ...
> > hwlocks = < 0>, < 1>, < 2>, < 3>;
> > hwlock-names = "glbl", "pool0", "pool1", "pool2";
> > };
> >
> > a-different-os-interface {
> > ...
> > hwlocks = < 18>, < 21>, < 4>, < 5>;
> > hwlock-names = "init", "teardown", "pool0", "pool1";
> > };
> >
> > That's the only way I would expect this to possibly remain a stable
> > over time, and it's the entire reason for #hwlock-cells, no?
> >
> > How do you expect the other components sharing the hwspinlocks to be
> > described?
>
> Yes indeed, this is what any of the clients will use on Linux. But
> this is not necessarily the semantics for exchanging hwlocks with the
> other processor(s) which is where the global id space comes into
> picture.
I did try to consider that above. Rather than thinking about the
numbering as "global", think of it as unique within the a given pool
shared between processors. That's what the "poolN" names are about
above.
That way you can dynamically allocate within the pool and know that
Linux and the SW on the other processors will use the same ID. You can
have pools that span multiple hwlock hardware blocks, and you can have
multiple separate pools in operation at once.
Surely that covers the cases you care about?
If using names is clunky, we could instead have a pool-hwlocks property
for that purpose.
Thanks,
Mark.
--
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] fs: btrfs: free-space-cache.c: remove two unnecessary checks before calling kfree()
> kfree checks whether the pointer it is passed is NULL. The two foregoing > checks are therefore unnecessary. > > This issue was detected using Coccinelle. Would you like to integrate my update suggestion "btrfs: Deletion of unnecessary checks before six function calls"? https://lkml.org/lkml/2014/10/31/606 http://article.gmane.org/gmane.linux.kernel/1818924 https://systeme.lip6.fr/pipermail/cocci/2014-October/001321.html Regards, Markus -- 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/
[GIT PULL] Updates to AFS filesystem
Hi Linus, Could you pull these updates to the AFS filesystem please? There are two sets: (1) Replacements of rcu_assign_pointer() with RCU_INIT_POINTER(). (2) Usage of 64-bit times on all arches to help deal with the 2038 problem. Thanks, David --- The following changes since commit dc6d6844111d953d3fa2121da28d38be9359c911: Merge tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband (2015-02-03 20:12:57 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/afs-20150211 for you to fetch changes up to 399cee992c718686f746745ea20d48b88ba195e2: afs: Prevent callback expiry timer overflow (2015-02-04 14:47:04 +) AFS updates Andreea-Cristina Bernat (2): afs: inode: Replace rcu_assign_pointer() with RCU_INIT_POINTER() afs: security: Replace rcu_assign_pointer() with RCU_INIT_POINTER() Tina Ruchandani (3): AFS: Correctly use 64-bit time for UUID afs: Migrate vlocation fields to 64-bit afs: Prevent callback expiry timer overflow fs/afs/callback.c | 7 --- fs/afs/fsclient.c | 2 +- fs/afs/inode.c | 9 + fs/afs/internal.h | 11 ++- fs/afs/main.c | 6 ++ fs/afs/security.c | 2 +- fs/afs/server.c| 6 +++--- fs/afs/vlocation.c | 16 +--- 8 files changed, 31 insertions(+), 28 deletions(-) -- 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 1/2] staging: unisys: remove unused variable
On Tue, Feb 10, 2015 at 02:34:15PM +0800, Greg Kroah-Hartman wrote: > On Tue, Feb 10, 2015 at 10:50:06AM +0530, Sudip Mukherjee wrote: > > > > > > But as I've missed this in the past, nevermind, I'll take it as is. Can > > > you resend your outstanding patches and I'll queue them up after > > > 3.20-rc1 is out. > > i will resend them now or should i send after the merge window closes? > > You can send patches any time, I'll batch them up and apply them to my > trees at the proper time. i have sent them as v2, i think i should have sent as [PATCH resend] :( sudip > -- 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 1/4] Documentation: dt: add common bindings for hwspinlock
Hi, Sorry I've been away from this thread for a while. On Wed, Feb 11, 2015 at 10:29:37AM +, Ohad Ben-Cohen wrote: > On Fri, Feb 6, 2015 at 2:34 AM, Bjorn Andersson wrote: > >> Yep, will do as soon as I hear from Ohad on what to do with the patch > >> "hwspinlock/core: maintain a list of registered hwspinlock banks" that I > >> dropped from v7. Without that and dropping hwlock-base-id, I can't get > >> the translations done. > >> > > > > My suggestion is to replace the global id-tree with a list of hwlocks > > and iterate over these if we ever get more than one driver registered. > > As long as #hwlock-drivers < log(#total-hwlocks) this should be > > faster. > > > > I would however argue that clients that would notice any kind of > > difference are using the API incorrectly. > > > > Unfortunately this is a somewhat larger change than just slapping DT > > support on the framework :/ > > I suspect we want to wait with framework changes until there's a real > hardware use case justifying them. > > With regard to DT, however, we obviously do want to be prepared for > multiple hwlock blocks even if they do not exist today. > > So how about adopting an approach where: > - DT fully supports multi hwlock blocks (i.e. no global id field) > - Framework left mostly unchanged at the moment. This means issuing an > explicit error in case a secondary hwlock block shows up, and then > hwlock id could trivially be the lock index. > > If multi hwlock hardware use case, or some new hwlock id translation > requirements, do show up in the future, it's always easy to add > framework support for it. At that point we'll know better what the > requirements are, and framework changes would be justifiable. As mentioned in my other reply I think we need to be explicit now when defining the set of hwlocks (and their namming/numbering) shared between a given set of processors, as we do with other resources (GPIOs/regulators/whatever). We also need to be explicit in describing the set of actors which use those locks. I think my previous proposal covered both of those. Thanks, Mark. -- 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 1/2] coresight: Adding coresight support for arm64 architecture
On Tue, Feb 10, 2015 at 09:31:24PM -0700, mathieu.poir...@linaro.org wrote: > From: Mathieu Poirier > > Most CoreSight blocks are 64-bit ready. As such move configuration > entries from "arch/arm/Kconfig.config" to the driver's subdirectory > and source the newly created Kconfig from architecture specific > Kconfig.debug files. > > Signed-off-by: Mathieu Poirier > --- > Change for v3: > - Separating Kconfig work from compilation warnings fixes. Nitpick: merge the compilation warnings fix first so that we don't get them once the Kconfig patch is merged for arm64. Acked-by: Catalin Marinas -- 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] ltc2941-battery-gauge: Fix typo in conversion formula (58 instead of 85)
The driver reported 30% less than actually measured. This turned out to
be caused by a simple typo in the formula to calculate the LSB quantity.
Signed-off-by: Mike Looijmans
---
drivers/power/ltc2941-battery-gauge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/ltc2941-battery-gauge.c
b/drivers/power/ltc2941-battery-gauge.c
index e4a9c87..784ff0b 100644
--- a/drivers/power/ltc2941-battery-gauge.c
+++ b/drivers/power/ltc2941-battery-gauge.c
@@ -439,7 +439,7 @@ static int ltc294x_i2c_probe(struct i2c_client *client,
} else {
if (prescaler_exp > LTC2941_MAX_PRESCALER_EXP)
prescaler_exp = LTC2941_MAX_PRESCALER_EXP;
- info->Qlsb = ((58 * 5) / r_sense) /
+ info->Qlsb = ((85 * 5) / r_sense) /
(128 / (1 << prescaler_exp));
}
--
1.9.1
--
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/
[drm-intel:drm-intel-next-queued 161/168] drivers/gpu/drm/i915/intel_ringbuffer.c:505:6: sparse: symbol 'intel_ring_setup_status_page' was not declared. Should it be static?
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: db275e69533f74b3d5cf2884cb8bba9d7640724d commit: 64a008c61c4615ba0fffd1cdae7d39b4246048f8 [161/168] drm/i915: Make intel_ring_setup_status_page() static reproduce: # apt-get install sparse git checkout 64a008c61c4615ba0fffd1cdae7d39b4246048f8 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/i915/intel_ringbuffer.c:505:6: sparse: symbol >> 'intel_ring_setup_status_page' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- 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 drm-intel] drm/i915: intel_ring_setup_status_page() can be static
drivers/gpu/drm/i915/intel_ringbuffer.c:505:6: sparse: symbol
'intel_ring_setup_status_page' was not declared. Should it be static?
Signed-off-by: Fengguang Wu
---
intel_ringbuffer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1b1fa8c..9ebc11e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -502,7 +502,7 @@ static void ring_setup_phys_status_page(struct
intel_engine_cs *ring)
I915_WRITE(HWS_PGA, addr);
}
-void intel_ring_setup_status_page(struct intel_engine_cs *ring)
+static void intel_ring_setup_status_page(struct intel_engine_cs *ring)
{
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = ring->dev->dev_private;
--
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/4] perf: add support for profiling jitted code
On Wed, Feb 11, 2015 at 12:42:41AM +0100, Stephane Eranian wrote: > To enable synchronization of the runtime MMAPs with those recorded by > the kernel on behalf of the perf tool, the runtime needs to timestamp > any record in the dump file using the same time source. The current > patch series is relying on Sonny Rao's posix-clock patch series > posted on LKML in 2013. The link to the patches is: > https://lkml.org/lkml/2013/12/6/1044 > At least for x86 you could use something like this: lkml.kernel.org/r/aa2dd2e4f1e9f2225758be5ba00f14d6909a8ce1.1423180257.git.s...@fb.com We can re-create the perf_clock() from the tsc with the mult, shift and offset provided in the perf userpage. -- 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: [RFC PATCH v1] usb: dwc2: reduce dwc2 driver probe time
Hi John Youn: Could you please give some suggestions from your point of view, about this probe time issue ? Thanks a lot. at 2015/2/11 2:23, Julius Werner wrote: @@ -2703,7 +2703,7 @@ int dwc2_get_hwparams(struct dwc2_hsotg *hsotg) gusbcfg = readl(hsotg->regs + GUSBCFG); gusbcfg &= ~GUSBCFG_FORCEHOSTMODE; writel(gusbcfg, hsotg->regs + GUSBCFG); - usleep_range(10, 15); + usleep_range(25000, 5); The point of usleep_range() is to coalesce multiple timer interrupts in idle systems for power efficiency. It's pretty pointless/harmful during probe anyway and there's almost never a reason to make the span larger than a few milliseconds. You should reduce this to something reasonable (e.g. usleep_range(25000, 26000) or even usleep_range(25000, 25000)) to save another chunk of time. Same applies to other delays above. do you know what's the upper boundary for AHB clock ? How fast can it be? It's not wise to change timers because "it works on my RK3288 board", you need to guarantee that this won't break anybody else. But this code is already a loop that spins on the AHBIdle bit, right? It should work correctly regardless of the delay. The only question is whether the code could be more efficient with a longer sleep... but since the general recommendation is to delay for ranges less than 10us, and the AHB clock would need to be lower than 100KHz (the ones I see are usually in the range of tens or hundreds of MHz) to take longer than that, this seems reasonable to me. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Roy Li @ Rockchip -- 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] fs: btrfs: free-space-cache.c: remove two unnecessary checks before calling kfree()
2015-02-11 12:30 GMT+01:00 SF Markus Elfring : >> kfree checks whether the pointer it is passed is NULL. The two foregoing >> checks are therefore unnecessary. >> >> This issue was detected using Coccinelle. > > Would you like to integrate my update suggestion "btrfs: Deletion of > unnecessary checks before six function calls"? > https://lkml.org/lkml/2014/10/31/606 > http://article.gmane.org/gmane.linux.kernel/1818924 > https://systeme.lip6.fr/pipermail/cocci/2014-October/001321.html Oh, I see you already made the exact same change. I'll just drop my patch in that case. > > Regards, > Markus > -- 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 0/5] Add support for Fujitsu USB host controller
On 10.02.2015 17:43, Sneeker Yeh wrote: > Hi > > 2015-01-31 0:38 GMT+08:00 Felipe Balbi : >> Hi, >> >> On Thu, Jan 29, 2015 at 10:23:12AM -0600, Felipe Balbi wrote: >>> On Tue, Jan 27, 2015 at 09:22:50AM -0600, Felipe Balbi wrote: Hi, On Sun, Jan 25, 2015 at 04:13:23PM +0800, Sneeker Yeh wrote: > These patches add support for XHCI compliant Host controller found > on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/ > The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 > driver > and last four patch is about quirk implementation of errata in Synopsis > DesignWare USB3 IP. > > Patch 1 introduces a quirk with device disconnection management necessary > Synopsys Designware USB3 IP with versions < 3.00a and hardware > configuration > DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the > quirk, that host controller will die after a usb device is disconnected > from > port of root hub. > > Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci > platform > data. > > Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare > USB3 > IP core driver. > > Patch 4 introduces using a quirk based on a errata of Synopsis > DesignWare USB3 IP which is versions < 3.00a and has hardware > configuration > DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. > As a > result this quirk has to be enabled via platform data or device tree. > > Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare > USB3 IP > driver. > Mathias, let me know how you want to handle this. Either I take them all, or you take them all. What do you prefer ? >>> >>> Mathias ? >> >> Mathias, a reminder on this series. > > Would any problem is still in my patchset? > e.g. I might still not arrange these patch in a appropriate order so > that Mathias cannot review and accept these? > Sorry about the delay. Let me take a better look at the first patch and reasons behind the race. I want to check if a quirk is enough or if we need to dig deeper into xhci. I'll try to do it today still -Mathias -- 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 1/6] ALSA: line6: Improve line6_read/write_data() interfaces
On Wed, Feb 11, 2015 at 3:33 AM, Takashi Iwai wrote: > At Tue, 10 Feb 2015 23:03:12 -0600, > Chris Rorvick wrote: >> >> Use explicit types to reflect the range of valid values. > > Well, this isn't necessarily to be changed at these places. If we > want to be safer, there should be proper range checks instead. > Also, readers may wonder when they see the different types between > read and write without explanations. Thanks, I'll send a v2 shortly. -- 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] fs: proc: inode.c: remove unnecessary type cast
Issue was detected using Coccinelle. Signed-off-by: Bas Peters --- fs/proc/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/inode.c b/fs/proc/inode.c index 8420a2f..e16ee87 100644 --- a/fs/proc/inode.c +++ b/fs/proc/inode.c @@ -57,7 +57,7 @@ static struct inode *proc_alloc_inode(struct super_block *sb) struct proc_inode *ei; struct inode *inode; - ei = (struct proc_inode *)kmem_cache_alloc(proc_inode_cachep, GFP_KERNEL); + ei = kmem_cache_alloc(proc_inode_cachep, GFP_KERNEL); if (!ei) return NULL; ei->pid = NULL; -- 2.1.0 -- 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 1/2] mmc: dw_mmc: fix bug that cause 'Timeout sending command'
Hi Alim,
On 02/11/2015 03:57 AM, Addy wrote:
>
> On 2015/02/10 23:22, Alim Akhtar wrote:
>> Hi Addy,
>>
>> On Mon, Feb 9, 2015 at 12:55 PM, Addy Ke wrote:
>>> Because of some uncertain factors, such as worse card or worse hardware,
>>> DAT[3:0](the data lines) may be pulled down by card, and mmc controller
>>> will be in busy state. This should not happend when mmc controller
>>> send command to update card clocks. If this happends, mci_send_cmd will
>>> be failed and we will get 'Timeout sending command', and then system will
>>> be blocked. To avoid this, we need reset mmc controller.
>>>
>>> Signed-off-by: Addy Ke
>>> ---
>>> drivers/mmc/host/dw_mmc.c | 28
>>> 1 file changed, 28 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 4d2e3c2..b0b57e3 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -100,6 +100,7 @@ struct idmac_desc {
>>> };
>>> #endif /* CONFIG_MMC_DW_IDMAC */
>>>
>>> +static int dw_mci_card_busy(struct mmc_host *mmc);
>>> static bool dw_mci_reset(struct dw_mci *host);
>>> static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
>>>
>>> @@ -888,6 +889,31 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32
>>> cmd, u32 arg)
>>> cmd, arg, cmd_status);
>>> }
>>>
>>> +static void dw_mci_wait_busy(struct dw_mci_slot *slot)
>>> +{
>>> + struct dw_mci *host = slot->host;
>>> + unsigned long timeout = jiffies + msecs_to_jiffies(500);
>>> +
>> Why 500 msec?
> This timeout value is the same as mci_send_cmd:
> static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg)
> {
> struct dw_mci *host = slot->host;
> unsigned long timeout = jiffies + msecs_to_jiffies(500);
>
> }
>
> I have not clear that which is suitable.
> Do you have any suggestion on it?
>>
>>> + do {
>>> + if (!dw_mci_card_busy(slot->mmc))
>>> + return;
>>> + cpu_relax();
>>> + } while (time_before(jiffies, timeout));
>>> +
>>> + dev_err(host->dev, "Data busy (status %#x)\n",
>>> + mci_readl(slot->host, STATUS));
>>> +
>>> + /*
>>> +* Data busy, this should not happend when mmc controller send
>>> command
>>> +* to update card clocks in non-volt-switch state. If it happends,
>>> we
>>> +* should reset controller to avoid getting "Timeout sending
>>> command".
>>> +*/
>>> + dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS);
>>> +
>> Why you need to reset all blocks? may be CTRL_RESET is good enough here.
> I have tested on rk3288, if only reset ctroller, data busy bit will not
> be cleaned,and we will still get
>
> "Timeout sending command".
>
>>
>>> + /* Fail to reset controller or still data busy, WARN_ON! */
>>> + WARN_ON(dw_mci_card_busy(slot->mmc));
>>> +}
>>> +
>>> static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit)
>>> {
>>> struct dw_mci *host = slot->host;
>>> @@ -899,6 +925,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot,
>>> bool force_clkinit)
>>> /* We must continue to set bit 28 in CMD until the change is
>>> complete */
>>> if (host->state == STATE_WAITING_CMD11_DONE)
>>> sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
>>> + else
>>> + dw_mci_wait_busy(slot);
>>>
>> hmm...I would suggest you to call dw_mci_wait_busy() from inside
>> mci_send_cmd(), seems like dw_mmc hangs while sending update clock cmd
>> in multiple cases.see [1]
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel.mmc/31140
> I think this patch is more reasonable.
> So I will resend patches based on this patch.
> thank you!
I have tested your patches instead [1] above and they do not solve my issue:
Board: odroid-xu3/exynos5422/dw_mmc_250a.
MMC card: absent, broken-cd quirk
SD card: present
System hangs during boot after few minutes kernel spits:
[ 242.188098] INFO: task kworker/u16:1:50 blocked for more than 120
seconds.
[ 242.193524] Not tainted
3.19.0-next-20150210-2-gf96831b-dirty #3834
[ 242.200622] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 242.208422] kworker/u16:1 D c04766ac 050 2 0x
[ 242.214756] Workqueue: kmmcd mmc_rescan
[ 242.218553] [] (__schedule) from []
(schedule+0x34/0x98)
[ 242.225591] [] (schedule) from []
(schedule_timeout+0x110/0x164)
[ 242.233302] [] (schedule_timeout) from []
(wait_for_common+0xb8/0x14c)
[ 242.241539] [] (wait_for_common) from []
(mmc_wait_for_req+0x68/0x17c)
[ 242.249861] [] (mmc_wait_for_req) from []
(mmc_wait_for_cmd+0x80/0xa0)
[ 242.258002] [] (mmc_wait_for_cmd) from []
(mmc_go_idle+0x78/0xf8)
[ 242.265796] [] (mmc_go_idle) from []
(mmc_rescan+0x280/0x314)
[ 242.273253] [] (mmc_rescan) from []
(process_one_work+0x120/0x324)
[ 242.281135] [] (process_one_work) from []
Re: [PATCH 3/4] perf inject: add jitdump mmap injection support
On Wed, Feb 11, 2015 at 12:42:44AM +0100, Stephane Eranian wrote: > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf > index aa6a504..c86c412 100644 > --- a/tools/perf/Makefile.perf > +++ b/tools/perf/Makefile.perf > @@ -496,7 +499,8 @@ BUILTIN_OBJS += $(OUTPUT)builtin-inject.o > BUILTIN_OBJS += $(OUTPUT)tests/builtin-test.o > BUILTIN_OBJS += $(OUTPUT)builtin-mem.o > > -PERFLIBS = $(LIB_FILE) $(LIBAPIKFS) $(LIBTRACEEVENT) > +PERFLIBS = $(LIB_FILE) $(LIBAPIKFS) $(LIBTRACEEVENT) -lcrypto > + Should we not add auto-detect magic for that? Otherwise perf will stop building on machines without libssl. -- 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] edac: fix memory leaks on failure path in edac_init()
On Fri, Feb 06, 2015 at 12:50:53PM +0100, Borislav Petkov wrote:
> On Thu, Feb 05, 2015 at 10:12:42PM -0800, Alexey Khoroshilov wrote:
> > edac_init() does not deallocate already allocated resources on failure path.
> >
> > Found by Linux Driver Verification project (linuxtesting.org).
> >
> > Signed-off-by: Alexey Khoroshilov
This causes section mismatches because the
edac_{debugfs,mc_sysfs}_exit() functions have __exit annotation but
you've added them to an __init-annotated function. And I should've
caught that :-\
Anyway, here's a fix I'm queueing ontop:
---
From: Borislav Petkov
Subject: [PATCH] EDAC: Fix section mismatches from edac_init unwind path
192580b45e8e ("EDAC: Properly unwind on failure path in edac_init()")
added an unwind path in case of error but those functions have __exit
annotation and are being used in an __init function, leading to section
mismatches. Drop the section annotation and make them normal functions.
Cc: Alexey Khoroshilov
Signed-off-by: Borislav Petkov
---
drivers/edac/edac_mc_sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 3a283819970b..112d63ad1154 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -914,7 +914,7 @@ int __init edac_debugfs_init(void)
return 0;
}
-void __exit edac_debugfs_exit(void)
+void edac_debugfs_exit(void)
{
debugfs_remove(edac_debugfs);
}
@@ -1155,7 +1155,7 @@ int __init edac_mc_sysfs_init(void)
return err;
}
-void __exit edac_mc_sysfs_exit(void)
+void edac_mc_sysfs_exit(void)
{
device_unregister(mci_pdev);
edac_put_sysfs_subsys();
--
2.2.0.33.gc18b867
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
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 v2] ALSA: line6: Improve line6_read/write_data() interfaces
The address cannot be negative so make it unsigned. Also, an unsigned
int is always sufficient for the length, so no need to overdo it with a
size_t. Finally, add in range checks to see if the values passed in
actually fit where they are used.
Signed-off-by: Chris Rorvick
---
This was dropped from an earlier series ("Cleanup reads/writes to Line 6
device memory".) This version leaves the arguements wide (within reason)
and does range checking.
Regards,
Chris
sound/usb/line6/driver.c | 14 ++
sound/usb/line6/driver.h | 8
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 99b63a7..4f82b57 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -302,14 +302,17 @@ static void line6_data_received(struct urb *urb)
/*
Read data from device.
*/
-int line6_read_data(struct usb_line6 *line6, int address, void *data,
- size_t datalen)
+int line6_read_data(struct usb_line6 *line6, unsigned address, void *data,
+ unsigned datalen)
{
struct usb_device *usbdev = line6->usbdev;
int ret;
unsigned char len;
unsigned count;
+ if (address > 0x || datalen > 0xff)
+ return EINVAL;
+
/* query the serial number: */
ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), 0x67,
USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
@@ -370,14 +373,17 @@ EXPORT_SYMBOL_GPL(line6_read_data);
/*
Write data to device.
*/
-int line6_write_data(struct usb_line6 *line6, int address, void *data,
-size_t datalen)
+int line6_write_data(struct usb_line6 *line6, unsigned address, void *data,
+unsigned datalen)
{
struct usb_device *usbdev = line6->usbdev;
int ret;
unsigned char status;
int count;
+ if (address > 0x || datalen > 0x)
+ return EINVAL;
+
ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), 0x67,
USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
0x0022, address, data, datalen,
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index 5d20294..7da643e 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -147,8 +147,8 @@ struct usb_line6 {
extern char *line6_alloc_sysex_buffer(struct usb_line6 *line6, int code1,
int code2, int size);
-extern int line6_read_data(struct usb_line6 *line6, int address, void *data,
- size_t datalen);
+extern int line6_read_data(struct usb_line6 *line6, unsigned address,
+ void *data, unsigned datalen);
extern int line6_read_serial_number(struct usb_line6 *line6,
u32 *serial_number);
extern int line6_send_raw_message_async(struct usb_line6 *line6,
@@ -161,8 +161,8 @@ extern void line6_start_timer(struct timer_list *timer,
unsigned long msecs,
void (*function)(unsigned long),
unsigned long data);
extern int line6_version_request_async(struct usb_line6 *line6);
-extern int line6_write_data(struct usb_line6 *line6, int address, void *data,
- size_t datalen);
+extern int line6_write_data(struct usb_line6 *line6, unsigned address,
+ void *data, unsigned datalen);
int line6_probe(struct usb_interface *interface,
const struct usb_device_id *id,
--
2.1.0
--
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] dmaengine: dw: support for clockless platforms
On Wed, 2015-02-11 at 10:10 +0800, Viresh Kumar wrote:
> On Tue, Jan 20, 2015 at 8:57 PM, Heikki Krogerus
> wrote:
> > When requesting clock in the platform driver, leaving
> > chip->clk value as NULL if -ENOENT is returned, and
> > continue. With other errors returning failure. It makes the
> > driver usable on platforms that do not provide the clock.
> >
> > Signed-off-by: Heikki Krogerus
> > ---
> > drivers/dma/dw/platform.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
> > index 32ea1ac..b183bc0 100644
> > --- a/drivers/dma/dw/platform.c
> > +++ b/drivers/dma/dw/platform.c
> > @@ -180,8 +180,12 @@ static int dw_probe(struct platform_device *pdev)
> > chip->dev = dev;
> >
> > chip->clk = devm_clk_get(chip->dev, "hclk");
> > - if (IS_ERR(chip->clk))
> > - return PTR_ERR(chip->clk);
> > + if (IS_ERR(chip->clk)) {
> > + if (PTR_ERR(chip->clk) == -ENOENT)
> > + chip->clk = NULL;
>
> This is wrong and reasons are mentioned in this thread:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/088437.html
Thanks for the link.
>
> You don't need to set it to NULL, if CONFIG_HAVE_CLK isn't set
> the dummy routines would take care of it.
Yeah, but in our case we have CONFIG_HAVE_CLK=y and no clk is provided
since IP is clockless. What could you suggest to do in such case?
--
Andy Shevchenko
Intel Finland Oy
--
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/
Problems with suspend on recent kernel (not necessary a bug)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi list, first, just punish me if I post on the wrong place for that but I think it it. :-) I moved recently my laptop (levovon X61s) from kernel version v3.13.11 to v3.18.6. Everything was fine except that suspend to RAM is not working anymore. Right after blanking the console the suspend stuck with still running fans and not reacting to any interrupt except hard switching of the box. I tried to debug that but with a blanked console it is pretty difficult to do so. At least I was able to set pm_trace and it gave me "tty ptyxc: hash matches". So there seems to be something with that subsystem I believe. Is there any further way to debug suspend that could give me more informations? As told in the subject, it might be a bug or not, I cannot say as there are several differences in config between that two versions without doing changes manually. This even makes it difficult to bisec the problem. Moreover that compiling need some time on that box. However, if there is no easier way, I plan to test at least with major versions... A small side note: I using the bfq patch. Currently I have no pointer of that being the source of the problem but could try to eliminate that too. So if anybody has an easy way to catch down that suspend beast, I would appreciate the help. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJU2z9dAAoJEKZ8CrGAGfase8kL/3NEj1cHA/bsbOc6Xo8T+9AY St43xkTX/Ex0zHYfCNfm4/s2gAi7yHgmeni/GXCYLBCEpcN4jBbrwYFHfsd02USm KglqkFqjklXw7lHaE6sclinSn5txe8tZbRqjWtRgrxgLU+7EoUQqF0Ozvvpc2teK d0VXdO+RpsGg7ZIcwyCr5b8dRKhLshjGgGIpk12kkdZZmRipu8V5u9Ls6j3tZj7h xCQ97GLsYd3bDhNWok/YVXNRPAmdLYtmnqkAYTSMDTUqtJZoNahVCZs0Z6qFfdPS ycPK1NtksNQSnlAYa7n7RlvbnWcytNklKBn1jIcdDKMH61+YnrQ9wYwpNkKu0VP7 idL84OlY85t5nJUhNpseJ3o6iwUu6826AKSzt76tlXNKY+ZhoqdMAC+3Ku58nsTP CFS63zjxmFMBTXjFak3bKnk7ZHKzJ7G24j257Qed/wnVE82kQ+17F0xHPjhbMj8I lc9goaDgiPRxCOA6NqM6RmlgC604/xPOrAKMH3AkMg== =OYh9 -END PGP SIGNATURE- -- 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] dmaengine: dw: support for clockless platforms
On Wed, Feb 11, 2015 at 02:02:39PM +0200, Andy Shevchenko wrote:
> On Wed, 2015-02-11 at 10:10 +0800, Viresh Kumar wrote:
> > > chip->clk = devm_clk_get(chip->dev, "hclk");
> > > - if (IS_ERR(chip->clk))
> > > - return PTR_ERR(chip->clk);
> > > + if (IS_ERR(chip->clk)) {
> > > + if (PTR_ERR(chip->clk) == -ENOENT)
> > > + chip->clk = NULL;
> >
> > You don't need to set it to NULL, if CONFIG_HAVE_CLK isn't set
> > the dummy routines would take care of it.
>
> Yeah, but in our case we have CONFIG_HAVE_CLK=y and no clk is provided
> since IP is clockless. What could you suggest to do in such case?
chip->clk = devm_clk_get(chip->dev, "hclk");
if (IS_ERR(chip->clk) && PTR_ERR(chip->clk) != -ENOENT)
return PTR_ERR(chip->clk);
You can then test for the presence of a clk via IS_ERR(chip->clk).
I'm just debating whether we should add a clk_is_valid() inline function
to linux/clk.h to avoid these shouting tests, and make it easier for
people test this in a generic manner.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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: bluetooth on n900 -- working patch
On Wed, Feb 11, 2015 at 10:41:36AM +, Pavel Machek wrote:
> Hi!
>
> Here's current version of the bluetooth patch, I hope I did not miss
> anything. This time including dts changes, so that driver is active.
>
> I have firmware in /lib/firmware/nokia/bcmfw.bin
>
> Best regards,
> Pavel
>
> Signed-off-by: Pavel Machek
>
> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
> b/Documentation/devicetree/bindings/serial/omap_serial.txt
> index 342eedd..e9fde42 100644
> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> @@ -4,7 +4,14 @@ Required properties:
> - compatible : should be "ti,omap2-uart" for OMAP2 controllers
> - compatible : should be "ti,omap3-uart" for OMAP3 controllers
> - compatible : should be "ti,omap4-uart" for OMAP4 controllers
> +- compatible : should be "ti+brcm,omap3-uart,bcm2048" for bcm2048
> + bluetooth connected to OMAP3 serial
As I mentioned previously, these should be separate devices, using the
UART as a bus.
NAK to this pseudo-composite device.
Mark.
> - ti,hwmods : Must be "uart", n being the instance number (1-based)
>
> Optional properties:
> - clock-frequency : frequency of the clock input to the UART
> +
> +Required properties for ti+brcm,omap3-uart,bcm2048:
> +- reset-gpios : gpio for reset pin
> +- host-wakeup-gpios : gpio for host wakeup
> +- bluetooth-wakeup-gpios : gpio for bluetooth wakeup
> diff --git a/arch/arm/boot/dts/omap3-n900.dts
> b/arch/arm/boot/dts/omap3-n900.dts
> index b550c41..e19bbe8 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -821,9 +867,19 @@
> };
>
> {
> +compatible = "ti+brcm,omap3-uart,bcm2048", "ti,omap3-uart";
> interrupts-extended = < 73 _pmx_core OMAP3_UART2_RX>;
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> +
> + clocks = <_fck>, <_ick>;
> + clock-names = "fck", "ick";
> +
> + device {
> + reset-gpios = < 27 GPIO_ACTIVE_HIGH>; /* 91 */
> + host-wakeup-gpios = < 5 GPIO_ACTIVE_HIGH>; /* 101 */
> + bluetooth-wakeup-gpios = < 5 GPIO_ACTIVE_HIGH>; /* 37
> */
> + };
> };
>
> {
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 01b7111..60e6d6b 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -275,7 +275,8 @@
> };
>
> uart2: serial@4806c000 {
> - compatible = "ti,omap3-uart";
> + // This is bluetooth on n900, ttyO1
> + compatible = "not-a-ti,omap3-not-a-uart";
> reg = <0x4806c000 0x400>;
> interrupts-extended = < 73>;
> dmas = < 51 52>;
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 364f080..e1e1935 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -244,4 +244,14 @@ config BT_WILINK
> Say Y here to compile support for Texas Instrument's WiLink7 driver
> into the kernel or say M to compile it as module (btwilink).
>
> +config BT_NOKIA_H4P
> + tristate "Nokia H4+ Extensions (H4P) driver"
> + help
> + Bluetooth HCI driver with H4 extensions. This driver provides
> + support for H4+ Bluetooth chip with vendor-specific H4 extensions.
> + It works on Broadcom based chip found in Nokia N900.
> +
> + Say Y here to compile support for h4 extended devices into the
> kernel
> + or say M to compile it as module (nokia_h4p).
> +
> endmenu
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index 9fe8a87..f1cc580 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -31,4 +31,8 @@ hci_uart-$(CONFIG_BT_HCIUART_ATH3K) += hci_ath.o
> hci_uart-$(CONFIG_BT_HCIUART_3WIRE)+= hci_h5.o
> hci_uart-objs := $(hci_uart-y)
>
> +obj-$(CONFIG_BT_NOKIA_H4P) += nokia_h4p.o
> +
> +nokia_h4p-y:= nokia_core.o nokia_fw.o nokia_uart.o
> +
> ccflags-y += -D__CHECK_ENDIAN__
> diff --git a/drivers/bluetooth/nokia_core.c b/drivers/bluetooth/nokia_core.c
> new file mode 100644
> index 000..ad461a9
> --- /dev/null
> +++ b/drivers/bluetooth/nokia_core.c
> @@ -0,0 +1,1140 @@
> +/*
> + * This file is part of Nokia H4P bluetooth driver
> + *
> + * Copyright (C) 2005-2008 Nokia Corporation.
> + * Copyright (C) 2014 Pavel Machek
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty
Re: [PATCH] fs: dlm: lockspace.c: removal of unnecessary check before calling kfree()
> kfree() checks its argument. It is therefore unnecessary to do this twice. > > This issue was detected using Coccinelle. Would you like to integrate my update suggestion 'fs-DLM: Deletion of unnecessary checks before the function call "kfree"'? https://lkml.org/lkml/2014/11/29/88 http://article.gmane.org/gmane.linux.kernel/1840524 https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg778279.html Regards, Markus -- 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: [RFC][PATCH] x86: nit: wrong page size in init_memory_mapping() printks
On Tue, Feb 10, 2015 at 01:20:30PM -0800, Dave Hansen wrote: > > From: Dave Hansen > > With 32-bit non-PAE kernels, we have 2 page sizes available > (at most): 4k and 4M. > > Enabling PAE replaces that 4M size with a 2M one (which 64-bit > systems use too). > > But, when booting a 32-bit non-PAE kernel, in one of our > early-boot printouts, we say: > > [0.00] init_memory_mapping: [mem 0x-0x000f] > [0.00] [mem 0x-0x000f] page 4k > [0.00] init_memory_mapping: [mem 0x3700-0x373f] > [0.00] [mem 0x3700-0x373f] page 2M > [0.00] init_memory_mapping: [mem 0x0010-0x36ff] > [0.00] [mem 0x0010-0x003f] page 4k > [0.00] [mem 0x0040-0x36ff] page 2M > [0.00] init_memory_mapping: [mem 0x3740-0x377fdfff] > [0.00] [mem 0x3740-0x377fdfff] page 4k > > Which is obviously wrong. There is no 2M page available. This > is probably because of a badly-named variable: in the map_range > code: PG_LEVEL_2M. > > Instead of renaming all the PG_LEVEL_2M's. This patch just > fixes the printout: > > [0.00] init_memory_mapping: [mem 0x-0x000f] > [0.00] [mem 0x-0x000f] page 4k > [0.00] init_memory_mapping: [mem 0x3700-0x373f] > [0.00] [mem 0x3700-0x373f] page 4M > [0.00] init_memory_mapping: [mem 0x0010-0x36ff] > [0.00] [mem 0x0010-0x003f] page 4k > [0.00] [mem 0x0040-0x36ff] page 4M > [0.00] init_memory_mapping: [mem 0x3740-0x377fdfff] > [0.00] [mem 0x3740-0x377fdfff] page 4k > [0.00] BRK [0x03206000, 0x03206fff] PGTABLE > > > Signed-off-by: Dave Hansen Looks ok to me considering that we're missing a PG_LEVEL_4M thing completely which would need to be handled depending on X86_PAE and CR4 PSE and PAE bits. Probably not worth the trouble though. Acked-by: Borislav Petkov -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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] fs: dlm: lockspace.c: removal of unnecessary check before calling kfree()
2015-02-11 13:10 GMT+01:00 SF Markus Elfring : >> kfree() checks its argument. It is therefore unnecessary to do this twice. >> >> This issue was detected using Coccinelle. > > Would you like to integrate my update suggestion 'fs-DLM: Deletion of > unnecessary checks before the function call "kfree"'? > https://lkml.org/lkml/2014/11/29/88 > http://article.gmane.org/gmane.linux.kernel/1840524 > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg778279.html I'll drop that too :) > Regards, > Markus > -- 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] fs: btrfs: free-space-cache.c: remove two unnecessary checks before calling kfree()
>> https://lkml.org/lkml/2014/10/31/606 >> http://article.gmane.org/gmane.linux.kernel/1818924 >> https://systeme.lip6.fr/pipermail/cocci/2014-October/001321.html > > Oh, I see you already made the exact same change. Would you like to add any tags to my update suggestion? Regards, Markus -- 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] dmaengine: dw: support for clockless platforms
On Wed, 2015-02-11 at 12:07 +, Russell King - ARM Linux wrote:
> On Wed, Feb 11, 2015 at 02:02:39PM +0200, Andy Shevchenko wrote:
> > On Wed, 2015-02-11 at 10:10 +0800, Viresh Kumar wrote:
> > > > chip->clk = devm_clk_get(chip->dev, "hclk");
> > > > - if (IS_ERR(chip->clk))
> > > > - return PTR_ERR(chip->clk);
> > > > + if (IS_ERR(chip->clk)) {
> > > > + if (PTR_ERR(chip->clk) == -ENOENT)
> > > > + chip->clk = NULL;
> > >
> > > You don't need to set it to NULL, if CONFIG_HAVE_CLK isn't set
> > > the dummy routines would take care of it.
> >
> > Yeah, but in our case we have CONFIG_HAVE_CLK=y and no clk is provided
> > since IP is clockless. What could you suggest to do in such case?
>
> chip->clk = devm_clk_get(chip->dev, "hclk");
> if (IS_ERR(chip->clk) && PTR_ERR(chip->clk) != -ENOENT)
> return PTR_ERR(chip->clk);
>
> You can then test for the presence of a clk via IS_ERR(chip->clk).
>
> I'm just debating whether we should add a clk_is_valid() inline function
> to linux/clk.h to avoid these shouting tests, and make it easier for
> people test this in a generic manner.
I guess clock framework may handle whatever is gotten from clk_get().
In driver much cleaner to use direct calls with exceptions (like you
can't get a valid clock rate from non-existing clock).
So, what about just passing by the error code and doing nothing?
--
Andy Shevchenko
Intel Finland Oy
--
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] fs: btrfs: free-space-cache.c: remove two unnecessary checks before calling kfree()
Markus, 2015-02-11 13:18 GMT+01:00 SF Markus Elfring : >>> https://lkml.org/lkml/2014/10/31/606 >>> http://article.gmane.org/gmane.linux.kernel/1818924 >>> https://systeme.lip6.fr/pipermail/cocci/2014-October/001321.html >> >> Oh, I see you already made the exact same change. > > Would you like to add any tags to my update suggestion? No, it's fine, I should've checked before submitting the patch. > > Regards, > Markus -- 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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms
Hello, On 2015-02-11 12:12, Russell King - ARM Linux wrote: On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote: On 2015-01-27 09:25, Sumit Semwal wrote: Add some helpers to share the constraints of devices while attaching to the dmabuf buffer. At each attach, the constraints are calculated based on the following: - max_segment_size, max_segment_count, segment_boundary_mask from device_dma_parameters. In case the attaching device's constraints don't match up, attach() fails. At detach, the constraints are recalculated based on the remaining attached devices. Two helpers are added: - dma_buf_get_constraints - which gives the current constraints as calculated during each attach on the buffer till the time, - dma_buf_recalc_constraints - which recalculates the constraints for all currently attached devices for the 'paranoid' ones amongst us. The idea of this patch is largely taken from Rob Clark's RFC at https://lkml.org/lkml/2012/7/19/285, and the comments received on it. Cc: Rob Clark Signed-off-by: Sumit Semwal The code looks okay, although it will probably will work well only with typical cases like 'contiguous memory needed' or 'no constraints at all' (iommu). Which is a damn good reason to NAK it - by that admission, it's a half-baked idea. If all we want to know is whether the importer can accept only contiguous memory or not, make a flag to do that, and allow the exporter to test this flag. Don't over-engineer this to make it _seem_ like it can do something that it actually totally fails with. As I've already pointed out, there's a major problem if you have already had a less restrictive attachment which has an active mapping, and a new more restrictive attachment comes along later. It seems from Rob's descriptions that we also need another flag in the importer to indicate whether it wants to have a valid struct page in the scatter list, or whether it (correctly) uses the DMA accessors on the scatter list - so that exporters can reject importers which are buggy. Okay, but flag-based approach also have limitations. Frankly, if we want to make it really portable and sharable between devices, then IMO we should get rid of struct scatterlist and replace it with simple array of pfns in dma_buf. This way at least the problem of missing struct page will be solved and the buffer representation will be also a bit more compact. Such solution however also requires extending dma-mapping API to handle mapping and unmapping of such pfn arrays. The advantage of this approach is the fact that it will be completely new API, so it can be designed well from the beginning. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland -- 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/
