Re: [PATCH 1/2] dt-bindings: iio: pressure: Add support for Honeywell HSC SPI sensors
On Fri, 26 Oct 2018 18:14:36 +
Carlos Iglesias wrote:
> Add device tree bindings for the HSC pressure sensors.
>
> Signed-off-by: Carlos Iglesias
> ---
> .../bindings/iio/pressure/hsc_spi.txt | 85 +++
> 1 file changed, 85 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/pressure/hsc_spi.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/pressure/hsc_spi.txt
> b/Documentation/devicetree/bindings/iio/pressure/hsc_spi.txt
> new file mode 100644
> index ..2302d6eef7c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/pressure/hsc_spi.txt
> @@ -0,0 +1,85 @@
> +Honeywell HSC Series of Pressure Sensors
> +
> +Pressure sensors from Honeywell with analog, I2C and SPI interfaces
> +
> +Required properties:
> +- compatible: selects the sensor model; must be one of the following
> + "honeywell,hsc001baa"
> + "honeywell,hsc001bab"
> + "honeywell,hsc001bac"
> + "honeywell,hsc001baf"
> + "honeywell,hsc1_6baa"
> + "honeywell,hsc1_6bab"
> + "honeywell,hsc1_6bac"
> + "honeywell,hsc1_6baf"
> + "honeywell,hsc2_5baa"
> + "honeywell,hsc2_5bab"
> + "honeywell,hsc2_5bac"
> + "honeywell,hsc2_5baf"
> + "honeywell,hsc004baa"
> + "honeywell,hsc004bab"
> + "honeywell,hsc004bac"
> + "honeywell,hsc004baf"
> + "honeywell,hsc006baa"
> + "honeywell,hsc006bab"
> + "honeywell,hsc006bac"
> + "honeywell,hsc006baf"
> + "honeywell,hsc010baa"
> + "honeywell,hsc010bab"
> + "honeywell,hsc010bac"
> + "honeywell,hsc010baf"
> + "honeywell,hsc100kaa"
> + "honeywell,hsc100kab"
> + "honeywell,hsc100kac"
> + "honeywell,hsc100kaf"
> + "honeywell,hsc160kaa"
> + "honeywell,hsc160kab"
> + "honeywell,hsc160kac"
> + "honeywell,hsc160kaf"
> + "honeywell,hsc250kaa"
> + "honeywell,hsc250kab"
> + "honeywell,hsc250kac"
> + "honeywell,hsc250kaf"
> + "honeywell,hsc400kaa"
> + "honeywell,hsc400kab"
> + "honeywell,hsc400kac"
> + "honeywell,hsc400kaf"
> + "honeywell,hsc600kaa"
> + "honeywell,hsc600kab"
> + "honeywell,hsc600kac"
> + "honeywell,hsc600kaf"
> + "honeywell,hsc001gaa"
> + "honeywell,hsc001gab"
> + "honeywell,hsc001gac"
> + "honeywell,hsc001gaf"
> + "honeywell,hsc015paa"
> + "honeywell,hsc015pab"
> + "honeywell,hsc015pac"
> + "honeywell,hsc015paf"
> + "honeywell,hsc030paa"
> + "honeywell,hsc030pab"
> + "honeywell,hsc030pac"
> + "honeywell,hsc030paf"
> + "honeywell,hsc060paa"
> + "honeywell,hsc060pab"
> + "honeywell,hsc060pac"
> + "honeywell,hsc060paf"
> + "honeywell,hsc100paa"
> + "honeywell,hsc100pab"
> + "honeywell,hsc100pac"
> + "honeywell,hsc100paf"
> + "honeywell,hsc150paa"
> + "honeywell,hsc150pab"
> + "honeywell,hsc150pac"
> + "honeywell,hsc150paf"
> +- reg: the SPI chip select number used by the sensor.
> +- spi-max-frequency: maximum clock frequency (Hz) used for the SPI bus.
> + The maximum value supported by the sensors is 40.
As Rob pointed out in a few reviews this week, the devicetree binding
for this should only be applying a tighter bound than either the
device or the bus master. So something introduced by the board
layout for example, or a level convertor..
Jonathan
> +
> +Example:
> +
> + hsc_spi0: hsc@0 {
> + compatible = "honeywell,hsc010baa";
> + reg = <0>;
> + spi-max-frequency = <40>;
> + };
Re: [GIT PULL] Qualcomm ARM64 DT updates for 4.20
On Thu, Oct 25, 2018 at 9:38 PM Andy Gross wrote: > > On Thu, Oct 25, 2018 at 10:55:32AM +0530, Amit Kucheria wrote: > > > > > Andy, > > > > While you acked the tsens thermal DT patches[1] so they could go > > through the thermal tree[2] to avoid a dependency, Eduardo would > > prefer the DT changes for tsens to go through the arch tree. > > > > To avoid a scenario where these DT changes don't get merged until the > > next merge window, would you or arm-soc maintainers consider merging > > them in -rc2 (after the thermal-soc tree gets merged)? > > > > For convenience, I've provided just the DT changes with all tags in a > > separate branch on top of v4.19 here: > > https://git.linaro.org/people/amit.kucheria/kernel.git/log/?h=up/thermal/tsens-preirq-cleanup-v4 > > > > Regards, > > Amit > > [1] Here is a reference to the patch series with Andy's acks: > > https://lore.kernel.org/lkml/cover.1536744310.git.amit.kuche...@linaro.org/T/ > > [2] Here is a link to Eduardo's tree containing a subset of the above > > series (I don't yet see a pull request): > > https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git/log/?h=linus > > I can just send a pull request for -rc1. No biggie. > Thanks Andy. FWIW, the dependency patches landed in Linus' tree.
Re: [PATCH 0/2] tracing: Fix synthetic event parser
On Sun, 28 Oct 2018 11:33:35 -0600 Shuah Khan wrote: > Hi Steve, > > Are there any dependencies on my pull request I sent to Linus? It hasn't > been pulled in yet. If there is one, could please you mention that in your > pull request for this. There's no dependency on the patches you took. But if you could ack the selftest one that would be awesome. Thanks, -- Steve
Re: [PATCH v2 1/2] staging: iio: ad7780: update voltage on read
On Sun, 28 Oct 2018 13:52:32 -0300 Renato Lui Geh wrote: > Hi Jonathan, > > Thank you for the review. > > >> + voltage_uv = regulator_get_voltage(st->reg); > >> + if (voltage_uv) > >> + st->int_vref_mv = voltage_uv/1000; > >>*val = st->int_vref_mv * st->gain; > >Is there actually a reason (now) to have the stashed value > >of int_vref_mv in the state structure? > > From probe: > > if (voltage_uv) > st->int_vref_mv = voltage_uv / 1000; > else > dev_warn(>dev, "Reference voltage unspecified\n"); > > So the idea was to, when voltage_uv = 0, return the previous voltage. > Should I instead handle this as an error the same way as in probe? > I would return it as an error. I can't really see how we would get this to occur if the bindings are all correct and appropriate driver support is there for the regulator to actually let us use it. If we wanted to handle the case of no regulator having been provided cleanly then we should it using an optional regulator get, and not provide the scale attribute at all if we can't know what it will read. This is a weird enough corner case though that I just wouldn't bother handling it as anything other than an error. > Thanks, > Renato Thanks, Jonathan
Re: i.MX6 MIPI-CSI2 OV5640 Camera testing on Mainline Linux
On Wed, Oct 24, 2018 at 9:17 AM Adam Ford wrote: > > On Wed, Oct 24, 2018 at 9:08 AM jacopo mondi wrote: > > > > Hi Adam, > > > > On Wed, Oct 24, 2018 at 08:53:41AM -0500, Adam Ford wrote: > > > On Tue, Oct 23, 2018 at 6:03 PM jacopo mondi wrote: > > > > > > > > Hi Adam, > > > > > > > > On Tue, Oct 23, 2018 at 12:54:12PM -0500, Adam Ford wrote: > > > > > On Tue, Oct 23, 2018 at 12:39 PM Steve Longerbeam > > > > > wrote: > > > > > > > > > > > > > > > > > > On 10/23/18 10:34 AM, Adam Ford wrote: > > > > > > > On Tue, Oct 23, 2018 at 11:36 AM Steve Longerbeam > > > > > > > wrote: > > > > > > >> Hi Adam, > > > > > > >> > > > > > > >> On 10/23/18 8:19 AM, Adam Ford wrote: > > > > > > >>> On Mon, Oct 22, 2018 at 7:40 AM Fabio Estevam > > > > > > >>> wrote: > > > > > > Hi Adam, > > > > > > > > > > > > On Mon, Oct 22, 2018 at 9:37 AM Adam Ford > > > > > > wrote: > > > > > > > > > > > > > Thank you! This tutorial web site is exactly what I need. > > > > > > > The > > > > > > > documentation page in Linux touched on the media-ctl links, > > > > > > > but it > > > > > > > didn't explain the syntax or the mapping. This graphical > > > > > > > interpretation really helps it make more sense. > > > > > > Is capturing working well on your i.MX6 board now? > > > > > > >>> Fabio, > > > > > > >>> > > > > > > >>> Unfortunately, no. I built the rootfs based on Jagan's > > > > > > >>> instructions > > > > > > >>> at > > > > > > >>> https://openedev.amarulasolutions.com/display/ODWIKI/i.CoreM6+1.5 > > > > > > >>> > > > > > > >>> I tried building both the 4.15-RC6 kernel, a 4.19 kernel and a > > > > > > >>> 4.14 LTS kernel. > > > > > > >>> > > > > > > >>> Using the suggested method of generating the graphical display > > > > > > >>> of the > > > > > > >>> pipeline options, I am able to enable various pipeline options > > > > > > >>> connecting different /dev/videoX options tot he camera. I have > > > > > > >>> tried > > > > > > >>> both the suggested method above as well as the instructions > > > > > > >>> found in > > > > > > >>> Documentation/media/v4l-drivers/imx.rst for their respective > > > > > > >>> kernels, > > > > > > >>> and I have tried multiple options to capture through > > > > > > >>> ipu1_csi1_capture, ipu2_csi1_capture, and ip1_ic_prepenc > > > > > > >>> capture, and > > > > > > >>> all yield a broken pipe. > > > > > > >>> > > > > > > >>> libv4l2: error turning on stream: Broken pipe > > > > > > >>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: > > > > > > >>> Could > > > > > > >>> not read from resource. > > > > > > >>> Additional debug info: > > > > > > >>> gstv4l2bufferpool.c(1064): gst_v4l2_buffer_pool_poll (): > > > > > > >>> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: > > > > > > >>> poll error 1: Broken pipe (32) > > > > > > >>> > > > > > > >>> I can hear the camera click when I start gstreamer and click > > > > > > >>> again > > > > > > >>> when it stops trying to stream. > > > > > > >>> > > > > > > >>> dmesg indicates a broken pipe as well.. > > > > > > >>> > > > > > > >>> [ 2419.851502] ipu2_csi1: pipeline start failed with -32 > > > > > > >>> > > > > > > >>> might you have any suggestions? > > > > > > >> > > > > > > >> This -EPIPE error might mean you have a mis-match of resolution, > > > > > > >> pixel > > > > > > >> format, or field type between one of the source->sink pad links. > > > > > > >> You can > > > > > > >> find out which pads have a mis-match by enabling dynamic debug > > > > > > >> in the > > > > > > >> kernel function __media_pipeline_start. > > > > > > > Following Jagan's suggestion, I tried to make sure all the > > > > > > > resolution > > > > > > > and pixel formats were set the same between each source and sink. > > > > > > > > > > > > > > media-ctl --set-v4l2 "'ov5640 2-0010':0[fmt:UYVY2X8/640x480 > > > > > > > field:none]" > > > > > > > media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY2X8/640x480 > > > > > > > field:none]" > > > > > > > media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/640x480 > > > > > > > field:none]" > > > > > > > media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/640x480 > > > > > > > field:none]" > > > > > > > > > > > > > >> Also make sure you are attempting to stream from the correct > > > > > > >> /dev/videoN. > > > > > > > I have graphically plotted the pipeline using media-ctl > > > > > > > --print-dot > > > > > > > and I can see the proper video is routed, but your dynamic debug > > > > > > > suggestion yielded something: > > > > > > > > > > > > > > imx-media capture-subsystem: link validation failed for > > > > > > > 'ov5640 > > > > > > > 2-0010':0 -> 'imx6-mipi-csi2':0, error -32 > > > > > > > > > > > > > > > > > > It's what I expected, you have a format mismatch between those pads. > > > > > > > > > > Is the mismatch something I am doing wrong with: > > > > > > > > > > media-ctl --set-v4l2 "'ov5640 2-0010':0[fmt:UYVY2X8/640x480 > > > > >
Re: [GIT PULL] XArray for 4.20
On Sun, Oct 28, 2018 at 12:13 PM Matthew Wilcox wrote: > > On Sun, Oct 28, 2018 at 11:50:19AM -0700, Linus Torvalds wrote: > > > NOTE! I did get some conflicts with other stuff, and while the > > conflict resolution all looked pretty straightforward, this does want > > looking at. > > > > Particularly the mm/workingset.c code. > > I've been rebasing the xarray-conv branch on your tree pretty regularly > this week, so I have a fairly good idea how I think it should look. > I'll check to see if you & I have the same thoughts when you push it out. It's pushed out now. I'm running the kernel now, but have done only basic boot testing (in addition to my usual build tests), no real stress-tests. Linus
[PATCH 5/9] w1: use octal numbers instead of macros for file mode
This satifies a warning raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index f64da16dbec9..bad2ee26cd4e 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -554,18 +554,18 @@ static ssize_t w1_master_attribute_store_remove(struct
device *dev,
w1_master_attribute_show_##_name,\
w1_master_attribute_store_##_name)
-static W1_MASTER_ATTR_RO(name, S_IRUGO);
-static W1_MASTER_ATTR_RO(slaves, S_IRUGO);
-static W1_MASTER_ATTR_RO(slave_count, S_IRUGO);
-static W1_MASTER_ATTR_RW(max_slave_count, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RO(attempts, S_IRUGO);
-static W1_MASTER_ATTR_RO(timeout, S_IRUGO);
-static W1_MASTER_ATTR_RO(timeout_us, S_IRUGO);
-static W1_MASTER_ATTR_RO(pointer, S_IRUGO);
-static W1_MASTER_ATTR_RW(search, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RW(pullup, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RW(add, S_IRUGO | S_IWUSR | S_IWGRP);
-static W1_MASTER_ATTR_RW(remove, S_IRUGO | S_IWUSR | S_IWGRP);
+static W1_MASTER_ATTR_RO(name, 0444);
+static W1_MASTER_ATTR_RO(slaves, 0444);
+static W1_MASTER_ATTR_RO(slave_count, 0444);
+static W1_MASTER_ATTR_RW(max_slave_count, 0664);
+static W1_MASTER_ATTR_RO(attempts, 0444);
+static W1_MASTER_ATTR_RO(timeout, 0444);
+static W1_MASTER_ATTR_RO(timeout_us, 0444);
+static W1_MASTER_ATTR_RO(pointer, 0444);
+static W1_MASTER_ATTR_RW(search, 0664);
+static W1_MASTER_ATTR_RW(pullup, 0664);
+static W1_MASTER_ATTR_RW(add, 0664);
+static W1_MASTER_ATTR_RW(remove, 0664);
static struct attribute *w1_master_default_attrs[] = {
_master_attribute_name.attr,
--
2.11.0
[PATCH 9/9] w1: using linux instead of asm prefix for includes
This fixes a warning raised by the checkpatch tool Signed-off-by: Steffen Vogel --- drivers/w1/w1_io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/w1/w1_io.c b/drivers/w1/w1_io.c index 283c89708c7c..b18d82cde71e 100644 --- a/drivers/w1/w1_io.c +++ b/drivers/w1/w1_io.c @@ -3,7 +3,7 @@ * Copyright (c) 2004 Evgeniy Polyakov */ -#include +#include #include #include -- 2.11.0
[PATCH 4/9] w1: cleanup whitespaces according to coding style document
These changes fix several warnings emitted by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 20 +---
drivers/w1/w1_family.c | 2 +-
drivers/w1/w1_io.c | 17 +
drivers/w1/w1_netlink.c | 2 +-
4 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 812186ce35d6..f64da16dbec9 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -775,7 +775,7 @@ int w1_attach_slave_device(struct w1_master *dev, struct
w1_reg_num *rn)
spin_lock(_flock);
f = w1_family_registered(rn->family);
if (!f) {
- f= _default_family;
+ f = _default_family;
dev_info(>dev, "Family %x for %02x.%012llx.%02x is not
registered.\n",
rn->family, rn->family,
(unsigned long long)rn->id, rn->crc);
@@ -997,7 +997,7 @@ void w1_search(struct w1_master *dev, u8 search_type,
desc_bit = 64;
- while ( !last_device && (slave_count++ < dev->max_slave_count) ) {
+ while (!last_device && (slave_count++ < dev->max_slave_count)) {
last_rn = rn;
rn = 0;
@@ -1045,7 +1045,7 @@ void w1_search(struct w1_master *dev, u8 search_type,
triplet_ret = w1_triplet(dev, search_bit);
/* quit if no device responded */
- if ( (triplet_ret & 0x03) == 0x03 )
+ if ((triplet_ret & 0x03) == 0x03)
break;
/* If both directions were valid, and we took the 0
path */
@@ -1064,13 +1064,12 @@ void w1_search(struct w1_master *dev, u8 search_type,
}
mutex_unlock(>bus_mutex);
- if ( (triplet_ret & 0x03) != 0x03 ) {
+ if ((triplet_ret & 0x03) != 0x03) {
if ((desc_bit == last_zero) || (last_zero < 0)) {
last_device = 1;
dev->search_id = 0;
- } else {
+ } else
dev->search_id = rn;
- }
desc_bit = last_zero;
cb(dev, rn);
}
@@ -1109,8 +1108,7 @@ void w1_search_process_cb(struct w1_master *dev, u8
search_type,
mutex_unlock(>list_mutex);
w1_slave_detach(sl);
mutex_lock(>list_mutex);
- }
- else if (test_bit(W1_SLAVE_ACTIVE, >flags))
+ } else if (test_bit(W1_SLAVE_ACTIVE, >flags))
sl->ttl = dev->slave_ttl;
}
mutex_unlock(>list_mutex);
@@ -1142,7 +1140,8 @@ int w1_process_callbacks(struct w1_master *dev)
list_for_each_entry_safe(async_cmd, async_n, >async_list,
async_entry) {
/* drop the lock, if it is a search it can take a long
-* time */
+* time
+*/
mutex_unlock(>list_mutex);
async_cmd->cb(dev, async_cmd);
ret = 1;
@@ -1199,8 +1198,7 @@ int w1_process(void *data)
if (!jremain)
jremain = jtime;
jremain = schedule_timeout(jremain);
- }
- else
+ } else
schedule();
}
diff --git a/drivers/w1/w1_family.c b/drivers/w1/w1_family.c
index ee90a6733472..5abbeb86de6e 100644
--- a/drivers/w1/w1_family.c
+++ b/drivers/w1/w1_family.c
@@ -83,7 +83,7 @@ EXPORT_SYMBOL(w1_unregister_family);
/*
* Should be called under w1_flock held.
*/
-struct w1_family * w1_family_registered(u8 fid)
+struct w1_family *w1_family_registered(u8 fid)
{
struct list_head *ent, *n;
struct w1_family *f = NULL;
diff --git a/drivers/w1/w1_io.c b/drivers/w1/w1_io.c
index 2626a61852e9..283c89708c7c 100644
--- a/drivers/w1/w1_io.c
+++ b/drivers/w1/w1_io.c
@@ -140,13 +140,13 @@ void w1_write_8(struct w1_master *dev, u8 byte)
if (dev->bus_master->write_byte) {
w1_pre_write(dev);
dev->bus_master->write_byte(dev->bus_master->data, byte);
- }
- else
+ } else {
for (i = 0; i < 8; ++i) {
if (i == 7)
w1_pre_write(dev);
w1_touch_bit(dev, (byte >> i) & 0x1);
}
+ }
w1_post_write(dev);
}
EXPORT_SYMBOL_GPL(w1_write_8);
@@ -236,9 +236,10 @@ u8 w1_read_8(struct w1_master *dev)
if (dev->bus_master->read_byte)
res = dev->bus_master->read_byte(dev->bus_master->data);
- else
+ else {
for (i = 0; i < 8; ++i)
- res |=
[PATCH 7/9] w1: use __func__ for logging the function name
This fixes a warning raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 3 ++-
drivers/w1/w1_int.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index e8ce97e066ec..c790c79352a0 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -1053,7 +1053,8 @@ void w1_search(struct w1_master *dev, u8 search_type,
if (test_bit(W1_ABORT_SEARCH, >flags)) {
mutex_unlock(>bus_mutex);
- dev_dbg(>dev, "Abort w1_search\n");
+ dev_dbg(>dev, "Abort %s\n", __func__);
+
return;
}
}
diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
index dd34d6a33f50..694b61ca1f85 100644
--- a/drivers/w1/w1_int.c
+++ b/drivers/w1/w1_int.c
@@ -98,7 +98,7 @@ int w1_add_master_device(struct w1_bus_master *master)
if (!(master->touch_bit && master->reset_bus) &&
!(master->write_bit && master->read_bit) &&
!(master->write_byte && master->read_byte && master->reset_bus)) {
- pr_err("w1_add_master_device: invalid function set\n");
+ pr_err("%s: invalid function set\n", __func__);
return(-EINVAL);
}
--
2.11.0
[PATCH 1/9] w1: add SPDX identifiers
This satisfies a checkpatch warning and is the preferred method for notating the license. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. Signed-off-by: Steffen Vogel --- drivers/w1/masters/ds1wm.c | 5 + drivers/w1/masters/ds2482.c| 7 ++- drivers/w1/masters/ds2490.c| 16 +--- drivers/w1/masters/matrox_w1.c | 16 +--- drivers/w1/masters/mxc_w1.c| 10 +- drivers/w1/masters/omap_hdq.c | 7 ++- drivers/w1/masters/w1-gpio.c | 5 + drivers/w1/slaves/w1_ds2405.c | 12 +--- drivers/w1/slaves/w1_ds2406.c | 4 +--- drivers/w1/slaves/w1_ds2408.c | 4 +--- drivers/w1/slaves/w1_ds2413.c | 4 +--- drivers/w1/slaves/w1_ds2423.c | 15 +-- drivers/w1/slaves/w1_ds2431.c | 4 +--- drivers/w1/slaves/w1_ds2433.c | 4 +--- drivers/w1/slaves/w1_ds2438.c | 4 +--- drivers/w1/slaves/w1_ds2780.c | 6 +- drivers/w1/slaves/w1_ds2781.c | 6 +- drivers/w1/slaves/w1_ds2805.c | 4 +--- drivers/w1/slaves/w1_ds28e04.c | 4 +--- drivers/w1/slaves/w1_ds28e17.c | 4 +--- drivers/w1/slaves/w1_smem.c| 16 +--- drivers/w1/slaves/w1_therm.c | 16 +--- drivers/w1/w1.c| 11 +-- drivers/w1/w1_family.c | 11 +-- drivers/w1/w1_int.c| 11 +-- drivers/w1/w1_internal.h | 11 +-- drivers/w1/w1_io.c | 11 +-- drivers/w1/w1_netlink.c| 11 +-- drivers/w1/w1_netlink.h| 11 +-- 29 files changed, 31 insertions(+), 219 deletions(-) diff --git a/drivers/w1/masters/ds1wm.c b/drivers/w1/masters/ds1wm.c index f661695fb589..83a991a3e3bd 100644 --- a/drivers/w1/masters/ds1wm.c +++ b/drivers/w1/masters/ds1wm.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * 1-wire busmaster driver for DS1WM and ASICs with embedded DS1WMs * such as HP iPAQs (including h5xxx, h2200, and devices with ASIC3 @@ -5,10 +6,6 @@ * * Copyright (c) 2004-2005, Szabolcs Gyurko * Copyright (c) 2004-2007, Matt Reimer - * - * Use consistent with the GNU GPL is permitted, - * provided that this copyright notice is - * preserved in its entirety in all copies and derived works. */ #include diff --git a/drivers/w1/masters/ds2482.c b/drivers/w1/masters/ds2482.c index 8b5e598ffdb3..d9bb021eca7e 100644 --- a/drivers/w1/masters/ds2482.c +++ b/drivers/w1/masters/ds2482.c @@ -1,4 +1,5 @@ -/** +// SPDX-License-Identifier: GPL-2.0 +/* * ds2482.c - provides i2c to w1-master bridge(s) * Copyright (C) 2005 Ben Gardner * @@ -7,10 +8,6 @@ * There are two variations: -100 and -800, which have 1 or 8 1-wire ports. * The complete datasheet can be obtained from MAXIM's website at: * http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4382 - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; version 2 of the License. */ #include diff --git a/drivers/w1/masters/ds2490.c b/drivers/w1/masters/ds2490.c index 0f4ecfcdb549..7bd9862ef337 100644 --- a/drivers/w1/masters/ds2490.c +++ b/drivers/w1/masters/ds2490.c @@ -1,22 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * ds2490.c USB to one wire bridge * * Copyright (c) 2004 Evgeniy Polyakov - * - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * 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. - * - * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include diff --git a/drivers/w1/masters/matrox_w1.c b/drivers/w1/masters/matrox_w1.c index d83d7c99d81d..be131c04ee63 100644 --- a/drivers/w1/masters/matrox_w1.c +++ b/drivers/w1/masters/matrox_w1.c @@ -1,22 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * matrox_w1.c * * Copyright (c) 2004 Evgeniy Polyakov - * - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * 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. - * - * You
[PATCH 2/9] w1: improve coding style by following strict 80 column line limit
This satisfies a checkpatch warning
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 56 +
drivers/w1/w1_int.c | 3 ++-
drivers/w1/w1_io.c | 29 +++--
drivers/w1/w1_netlink.c | 16 +-
4 files changed, 64 insertions(+), 40 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 2c64655b603c..bd95dfe4041d 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -85,7 +85,8 @@ static void w1_slave_release(struct device *dev)
sl->master->slave_count--;
}
-static ssize_t name_show(struct device *dev, struct device_attribute *attr,
char *buf)
+static ssize_t name_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct w1_slave *sl = dev_to_w1_slave(dev);
@@ -203,9 +204,10 @@ struct device w1_slave_device = {
.driver = _slave_driver,
.release = _slave_release
};
-#endif /* 0 */
+#endif
-static ssize_t w1_master_attribute_show_name(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_name(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
@@ -217,9 +219,9 @@ static ssize_t w1_master_attribute_show_name(struct device
*dev, struct device_a
return count;
}
-static ssize_t w1_master_attribute_store_search(struct device * dev,
+static ssize_t w1_master_attribute_store_search(struct device *dev,
struct device_attribute *attr,
- const char * buf, size_t count)
+ const char *buf, size_t count)
{
long tmp;
struct w1_master *md = dev_to_w1_master(dev);
@@ -286,7 +288,8 @@ static ssize_t w1_master_attribute_show_pullup(struct
device *dev,
return count;
}
-static ssize_t w1_master_attribute_show_pointer(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_pointer(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
@@ -297,7 +300,8 @@ static ssize_t w1_master_attribute_show_pointer(struct
device *dev, struct devic
return count;
}
-static ssize_t w1_master_attribute_show_timeout(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_timeout(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
ssize_t count;
count = sprintf(buf, "%d\n", w1_timeout);
@@ -330,7 +334,8 @@ static ssize_t
w1_master_attribute_store_max_slave_count(struct device *dev,
return count;
}
-static ssize_t w1_master_attribute_show_max_slave_count(struct device *dev,
struct device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_max_slave_count(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
@@ -338,10 +343,12 @@ static ssize_t
w1_master_attribute_show_max_slave_count(struct device *dev, stru
mutex_lock(>mutex);
count = sprintf(buf, "%d\n", md->max_slave_count);
mutex_unlock(>mutex);
+
return count;
}
-static ssize_t w1_master_attribute_show_attempts(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_attempts(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
@@ -349,10 +356,12 @@ static ssize_t w1_master_attribute_show_attempts(struct
device *dev, struct devi
mutex_lock(>mutex);
count = sprintf(buf, "%lu\n", md->attempts);
mutex_unlock(>mutex);
+
return count;
}
-static ssize_t w1_master_attribute_show_slave_count(struct device *dev, struct
device_attribute *attr, char *buf)
+static ssize_t w1_master_attribute_show_slave_count(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct w1_master *md = dev_to_w1_master(dev);
ssize_t count;
@@ -408,8 +417,7 @@ static int w1_atoreg_num(struct device *dev, const char
*buf, size_t count,
* print it either. It would be unreasonable for the user to then
* provide it.
*/
- const char *error_msg = "bad slave string format, expecting "
- "ff-\n";
+ const char *error_msg = "bad slave string format, expecting
ff-\n";
if (buf[2] != '-') {
dev_err(dev, "%s", error_msg);
@@ -880,8 +888,8 @@ void w1_reconnect_slaves(struct w1_family *f, int attach)
mutex_lock(_mlock);
list_for_each_entry(dev, _masters, w1_master_entry) {
- dev_dbg(>dev, "Reconnecting
[PATCH 8/9] w1: fix whitespaces of struct declarations
This fixes a warning raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1_netlink.h | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/w1/w1_netlink.h b/drivers/w1/w1_netlink.h
index 08cbf08f3649..7873eb54352e 100644
--- a/drivers/w1/w1_netlink.h
+++ b/drivers/w1/w1_netlink.h
@@ -61,19 +61,18 @@ enum w1_netlink_message_types {
* The netlink connector data sequence is, struct nlmsghdr, struct cn_msg,
* then one or more struct w1_netlink_msg (each with optional data).
*/
-struct w1_netlink_msg
-{
- __u8type;
- __u8status;
- __u16 len;
+struct w1_netlink_msg {
+ __u8 type;
+ __u8 status;
+ __u16 len;
union {
- __u8id[8];
+ __u8 id[8];
struct w1_mst {
- __u32 id;
- __u32 res;
+ __u32 id;
+ __u32 res;
} mst;
} id;
- __u8data[0];
+ __u8 data[0];
};
/**
@@ -117,12 +116,11 @@ enum w1_commands {
* One or more struct w1_netlink_cmd is placed starting at w1_netlink_msg.data
* each with optional data.
*/
-struct w1_netlink_cmd
-{
- __u8cmd;
- __u8res;
- __u16 len;
- __u8data[0];
+struct w1_netlink_cmd {
+ __u8 cmd;
+ __u8 res;
+ __u16 len;
+ __u8 data[0];
};
#ifdef __KERNEL__
--
2.11.0
[RFR] Store tearing
Hi, memory-barriers.txt says: [on "store tearing"] "In fact, a recent bug (since fixed) caused GCC to incorrectly use this optimization in a volatile store.". I was wondering if you could help me retrieve some reference/discussions about this? Thanks, Andrea
linux-next: manual merge of the arm-soc tree with Linus' tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in:
include/linux/platform_data/gpio-omap.h
between commit:
b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead")
from Linus' tree and commit:
26683316c92a ("ARM: OMAP1: ams-delta-fiq: Use
")
from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/platform_data/gpio-omap.h
index 8485c6a9a383,ed071f76b642..
--- a/include/linux/platform_data/gpio-omap.h
+++ b/include/linux/platform_data/gpio-omap.h
@@@ -205,4 -206,18 +208,6 @@@ struct omap_gpio_platform_data
int (*get_context_loss_count)(struct device *dev);
};
-#if IS_BUILTIN(CONFIG_GPIO_OMAP)
-extern void omap2_gpio_prepare_for_idle(int off_mode);
-extern void omap2_gpio_resume_after_idle(void);
-#else
-static inline void omap2_gpio_prepare_for_idle(int off_mode)
-{
-}
-
-static inline void omap2_gpio_resume_after_idle(void)
-{
-}
-#endif
+ #endif /* __ASSEMBLER__ */
+
#endif
pgpAj4cUztXGY.pgp
Description: OpenPGP digital signature
Re: [PATCH 6/8] clk: s2mps11: constify clk_ops structure
On 2018년 10월 27일 14:47, Julia Lawall wrote:
> The clk_ops structure is only stored in the ops fields of
> clk_init_data structures. This field is const, so the clk_ops
> structure can be const as well.
>
> Identified and transformed using Coccinelle.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/clk/clk-s2mps11.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
> index 5b419b82f7ca..2ce370c804aa 100644
> --- a/drivers/clk/clk-s2mps11.c
> +++ b/drivers/clk/clk-s2mps11.c
> @@ -71,7 +71,7 @@ static unsigned long s2mps11_clk_recalc_rate(struct clk_hw
> *hw,
> return 32768;
> }
>
> -static struct clk_ops s2mps11_clk_ops = {
> +static const struct clk_ops s2mps11_clk_ops = {
> .prepare= s2mps11_clk_prepare,
> .unprepare = s2mps11_clk_unprepare,
> .is_prepared= s2mps11_clk_is_prepared,
>
>
>
Looks good to me.
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [RFC] rcu: doc: update example about stale data
On Sun, Oct 28, 2018 at 10:21:42AM -0700, Paul E. McKenney wrote: > On Sat, Oct 27, 2018 at 07:16:53PM -0700, Joel Fernandes (Google) wrote: > > The RCU example for 'rejecting stale data' on system-call auditting > > stops iterating through the rules if a deleted one is found. It makes > > more sense to continue looking at other rules once a deleted one is > > rejected. Although the original example is fine, this makes it more > > meaningful. > > > > Signed-off-by: Joel Fernandes (Google) > > Does the actual audit code that this was copied from now include the > continue statement? If so, please update the commit log to state that > and then I will take the resulting patch. (This example was inspired > by a long-ago version of the actual audit code.) The document talks of a situation that could be but is not really in the implementation. It says "If the system-call audit module were to ever need to reject stale data". So its not really something implemented. I was just correcting the example you had there since it made more sense to me to continue looking for other rules in the list once a rule was shown to be stale. It just makes the example more correct. But I'm Ok if you want to leave that alone ;-) Hence, the RFC tag to this patch ;-) - Joel
linux-next: manual merge of the vfs tree with the ceph tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/ceph/file.c
between commit:
fce7a9744bdf ("ceph: refactor ceph_sync_read()")
from the ceph tree and commit:
00e23707442a ("iov_iter: Use accessor function")
from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/ceph/file.c
index f788496fafcc,5dd433aa9b23..
--- a/fs/ceph/file.c
+++ b/fs/ceph/file.c
@@@ -594,103 -658,48 +594,103 @@@ static ssize_t ceph_sync_read(struct ki
if (ret < 0)
return ret;
- if (unlikely(iov_iter_is_pipe(to))) {
+ ret = 0;
+ while ((len = iov_iter_count(to)) > 0) {
+ struct ceph_osd_request *req;
+ struct page **pages;
+ int num_pages;
size_t page_off;
- ret = iov_iter_get_pages_alloc(to, , len,
- _off);
- if (ret <= 0)
- return -ENOMEM;
- num_pages = DIV_ROUND_UP(ret + page_off, PAGE_SIZE);
+ u64 i_size;
+ bool more;
+
+ req = ceph_osdc_new_request(osdc, >i_layout,
+ ci->i_vino, off, , 0, 1,
+ CEPH_OSD_OP_READ, CEPH_OSD_FLAG_READ,
+ NULL, ci->i_truncate_seq,
+ ci->i_truncate_size, false);
+ if (IS_ERR(req)) {
+ ret = PTR_ERR(req);
+ break;
+ }
+
+ more = len < iov_iter_count(to);
- if (unlikely(to->type & ITER_PIPE)) {
- ret = striped_read(inode, off, ret, pages, num_pages,
- page_off, checkeof);
- if (ret > 0) {
- iov_iter_advance(to, ret);
- off += ret;
++ if (unlikely(iov_iter_is_pipe(to))) {
+ ret = iov_iter_get_pages_alloc(to, , len,
+ _off);
+ if (ret <= 0) {
+ ceph_osdc_put_request(req);
+ ret = -ENOMEM;
+ break;
+ }
+ num_pages = DIV_ROUND_UP(ret + page_off, PAGE_SIZE);
+ if (ret < len) {
+ len = ret;
+ osd_req_op_extent_update(req, 0, len);
+ more = false;
+ }
} else {
- iov_iter_advance(to, 0);
+ num_pages = calc_pages_for(off, len);
+ page_off = off & ~PAGE_MASK;
+ pages = ceph_alloc_page_vector(num_pages, GFP_KERNEL);
+ if (IS_ERR(pages)) {
+ ceph_osdc_put_request(req);
+ ret = PTR_ERR(pages);
+ break;
+ }
}
- ceph_put_page_vector(pages, num_pages, false);
- } else {
- num_pages = calc_pages_for(off, len);
- pages = ceph_alloc_page_vector(num_pages, GFP_KERNEL);
- if (IS_ERR(pages))
- return PTR_ERR(pages);
-
- ret = striped_read(inode, off, len, pages, num_pages,
- (off & ~PAGE_MASK), checkeof);
- if (ret > 0) {
- int l, k = 0;
- size_t left = ret;
-
- while (left) {
- size_t page_off = off & ~PAGE_MASK;
- size_t copy = min_t(size_t, left,
- PAGE_SIZE - page_off);
- l = copy_page_to_iter(pages[k++], page_off,
-copy, to);
- off += l;
- left -= l;
- if (l < copy)
+
+ osd_req_op_extent_osd_data_pages(req, 0, pages, len, page_off,
+ false, false);
+ ret = ceph_osdc_start_request(osdc, req, false);
+ if (!ret)
+ ret = ceph_osdc_wait_request(osdc, req);
+ ceph_osdc_put_request(req);
+
+ i_size = i_size_read(inode);
+ dout("sync_read %llu~%llu got
[PATCH v6 3/3] staging: iio: ad2s1210: Add device tree support.
Replace platform data with device tree support.
Signed-off-by: Nishad Kamdar
---
drivers/staging/iio/resolver/Kconfig| 1 +
drivers/staging/iio/resolver/ad2s1210.c | 17 -
drivers/staging/iio/resolver/ad2s1210.h | 17 -
3 files changed, 9 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/iio/resolver/Kconfig
b/drivers/staging/iio/resolver/Kconfig
index 6a469ee6101f..cc1202ff813d 100644
--- a/drivers/staging/iio/resolver/Kconfig
+++ b/drivers/staging/iio/resolver/Kconfig
@@ -15,6 +15,7 @@ config AD2S90
config AD2S1210
tristate "Analog Devices ad2s1210 driver"
+ depends on OF
depends on SPI
depends on GPIOLIB || COMPILE_TEST
help
diff --git a/drivers/staging/iio/resolver/ad2s1210.c
b/drivers/staging/iio/resolver/ad2s1210.c
index 0234869e9d74..5ecdb5785132 100644
--- a/drivers/staging/iio/resolver/ad2s1210.c
+++ b/drivers/staging/iio/resolver/ad2s1210.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -76,7 +77,6 @@ struct ad2s1210_gpio {
};
struct ad2s1210_state {
- const struct ad2s1210_platform_data *pdata;
struct mutex lock;
struct spi_device *sdev;
struct gpio_desc *sample;
@@ -84,6 +84,7 @@ struct ad2s1210_state {
struct gpio_desc *a1;
struct gpio_desc *res0;
struct gpio_desc *res1;
+ bool gpioin;
unsigned int fclkin;
unsigned int fexcit;
bool hysteresis;
@@ -314,7 +315,7 @@ static ssize_t ad2s1210_store_control(struct device *dev,
}
st->resolution
= ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
- if (st->pdata->gpioin) {
+ if (st->gpioin) {
data = ad2s1210_read_resolution_pin(st);
if (data != st->resolution)
dev_warn(dev, "ad2s1210: resolution settings not
match\n");
@@ -376,7 +377,7 @@ static ssize_t ad2s1210_store_resolution(struct device *dev,
}
st->resolution
= ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
- if (st->pdata->gpioin) {
+ if (st->gpioin) {
data = ad2s1210_read_resolution_pin(st);
if (data != st->resolution)
dev_warn(dev, "ad2s1210: resolution settings not
match\n");
@@ -603,7 +604,7 @@ static int ad2s1210_initial(struct ad2s1210_state *st)
int ret;
mutex_lock(>lock);
- if (st->pdata->gpioin)
+ if (st->gpioin)
st->resolution = ad2s1210_read_resolution_pin(st);
else
ad2s1210_set_resolution_pin(st);
@@ -644,7 +645,7 @@ static int ad2s1210_setup_gpios(struct ad2s1210_state *st)
int ret, i;
struct spi_device *spi = st->sdev;
struct ad2s1210_gpio *pin;
- unsigned long flags = st->pdata->gpioin ? GPIOD_IN : GPIOD_OUT_LOW;
+ unsigned long flags = st->gpioin ? GPIOD_IN : GPIOD_OUT_LOW;
struct ad2s1210_gpio gpios[] = {
{ .ptr = >sample, .name = "sample", .flags = GPIOD_IN },
@@ -673,16 +674,14 @@ static int ad2s1210_probe(struct spi_device *spi)
{
struct iio_dev *indio_dev;
struct ad2s1210_state *st;
+ struct device_node *np = spi->dev.of_node;
int ret;
- if (!spi->dev.platform_data)
- return -EINVAL;
-
indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
if (!indio_dev)
return -ENOMEM;
st = iio_priv(indio_dev);
- st->pdata = spi->dev.platform_data;
+ st->gpioin = of_property_read_bool(np, "gpioin");
ret = ad2s1210_setup_gpios(st);
if (ret < 0)
return ret;
diff --git a/drivers/staging/iio/resolver/ad2s1210.h
b/drivers/staging/iio/resolver/ad2s1210.h
index 63d479b20a6c..e69de29bb2d1 100644
--- a/drivers/staging/iio/resolver/ad2s1210.h
+++ b/drivers/staging/iio/resolver/ad2s1210.h
@@ -1,17 +0,0 @@
-/*
- * ad2s1210.h plaform data for the ADI Resolver to Digital Converters:
- * AD2S1210
- *
- * Copyright (c) 2010-2010 Analog Devices Inc.
- *
- * 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.
- */
-#ifndef _AD2S1210_H
-#define _AD2S1210_H
-
-struct ad2s1210_platform_data {
- boolgpioin;
-};
-#endif /* _AD2S1210_H */
--
2.17.1
Re: [Outreachy kernel] [RESEND PATCH 2/2] staging: vboxvideo: Use unsigned int instead bool
Hi Sasha,
On Fri, Oct 26, 2018 at 04:42:25PM -0400, Sasha Levin wrote:
> On Fri, Oct 26, 2018 at 04:04:45PM -0300, Shayenne da Luz Moura wrote:
> > This change was suggested by checkpath.pl. Use unsigned int with bitfield
> > allocate only one bit to the boolean variable.
> >
> > CHECK: Avoid using bool structure members because of possible alignment
> > issues
> >
> > Signed-off-by: Shayenne da Luz Moura
> > ---
> > drivers/staging/vboxvideo/vbox_drv.h| 14 +++---
> > drivers/staging/vboxvideo/vboxvideo_guest.h | 2 +-
> > 2 files changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/staging/vboxvideo/vbox_drv.h
> > b/drivers/staging/vboxvideo/vbox_drv.h
> > index 594f84272957..7d3e329a6b1c 100644
> > --- a/drivers/staging/vboxvideo/vbox_drv.h
> > +++ b/drivers/staging/vboxvideo/vbox_drv.h
> > @@ -81,7 +81,7 @@ struct vbox_private {
> > u8 __iomem *vbva_buffers;
> > struct gen_pool *guest_pool;
> > struct vbva_buf_ctx *vbva_info;
> > - bool any_pitch;
> > + unsigned int any_pitch:1;
> > u32 num_crtcs;
> > /** Amount of available VRAM, including space used for buffers. */
> > u32 full_vram_size;
>
> Using bitfields for booleans in these cases is less efficient than just
> using "regular" booleans for two reasons:
>
> 1. It will use the same amount of space. Due to alignment requirements,
> the compiler can't squeeze in anything into the 7 bits that are now
> "free". Each member, unless it's another bitfield, must start at a whole
> byte.
Agreed!
FYI original thread of discussion: https://lkml.org/lkml/2017/11/21/207
As Steve says:
"Thus, changing:
int a : 1;
int b : 1;
int c : 1;
int d : 1;
to
bool a;
bool b;
bool c;
bool d;
at best increases the size required from 1 byte to 4 bytes, and at
worse, it increases it from one byte to 16 bytes."
In the above cases, we have all bitfields members and no non-bitfields
members.
But before playing with these bitfields there are some points to be
noted:
https://port70.net/~nsz/c/c11/n1570.html#J.3.9
Implementation Defined
--
* Whether a ''plain'' int bit-field is treated as a signed int
bit-field or as an unsigned int bit-field.
eg: `int foo:3` may have a range from 0..7 or -4..3
So, changing `int foo:3` to `unsigned int foo:3` might be a sane
change to remove the ambiguity and make sure range is 0..7.
Also, such an change can also handle unsigned overflow
or better said "wrapping".
* Whether a bit-field can straddle a storage-unit boundary.
So, you can't guess what could be the possible unless you're familiar
or tested the change for different arch.
* The alignment of non-bit-field members of structures.
...
The "possible alignement issues" in CHECK report is difficult to figure
out by just doing a glance analysis. :)
Linus also suggested to use bool as the base type i.e., `bool x:1` but
again sizeof(_Bool) is implementation defined ranging from 1-4 bytes.
And since this issue is added to checkpatch now, very likely there would
be blast of patches sent on the same.
Not everyone who sends checkpatch would be able to disassemble or test
on different implementations.
But if anyone is interested check this:
https://godbolt.org/
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology
[PATCH v6 2/3] staging: iio: ad2s1210: Add device tree table.
Add device tree table for matching vendor ID.
Signed-off-by: Nishad Kamdar
---
drivers/staging/iio/resolver/ad2s1210.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/staging/iio/resolver/ad2s1210.c
b/drivers/staging/iio/resolver/ad2s1210.c
index 93c3c70ce62e..0234869e9d74 100644
--- a/drivers/staging/iio/resolver/ad2s1210.c
+++ b/drivers/staging/iio/resolver/ad2s1210.c
@@ -724,6 +724,12 @@ static int ad2s1210_remove(struct spi_device *spi)
return 0;
}
+static const struct of_device_id ad2s1210_of_match[] = {
+ { .compatible = "adi,ad2s1210", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ad2s1210_of_match);
+
static const struct spi_device_id ad2s1210_id[] = {
{ "ad2s1210" },
{}
@@ -733,6 +739,7 @@ MODULE_DEVICE_TABLE(spi, ad2s1210_id);
static struct spi_driver ad2s1210_driver = {
.driver = {
.name = DRV_NAME,
+ .of_match_table = of_match_ptr(ad2s1210_of_match),
},
.probe = ad2s1210_probe,
.remove = ad2s1210_remove,
--
2.17.1
Re: INFO: rcu detected stall in do_idle
On 27/10/18 12:16, Dmitry Vyukov wrote:
> On Wed, Oct 24, 2018 at 1:03 PM, Juri Lelli wrote:
> >
> > On 19/10/18 22:50, luca abeni wrote:
> > > On Fri, 19 Oct 2018 13:39:42 +0200
> > > Peter Zijlstra wrote:
> > >
> > > > On Thu, Oct 18, 2018 at 01:08:11PM +0200, luca abeni wrote:
> > > > > Ok, I see the issue now: the problem is that the "while
> > > > > (dl_se->runtime <= 0)" loop is executed at replenishment time, but
> > > > > the deadline should be postponed at enforcement time.
> > > > >
> > > > > I mean: in update_curr_dl() we do:
> > > > > dl_se->runtime -= scaled_delta_exec;
> > > > > if (dl_runtime_exceeded(dl_se) || dl_se->dl_yielded) {
> > > > > ...
> > > > > enqueue replenishment timer at dl_next_period(dl_se)
> > > > > But dl_next_period() is based on a "wrong" deadline!
> > > > >
> > > > >
> > > > > I think that inserting a
> > > > > while (dl_se->runtime <= -pi_se->dl_runtime) {
> > > > > dl_se->deadline += pi_se->dl_period;
> > > > > dl_se->runtime += pi_se->dl_runtime;
> > > > > }
> > > > > immediately after "dl_se->runtime -= scaled_delta_exec;" would fix
> > > > > the problem, no?
> > > >
> > > > That certainly makes sense to me.
> > >
> > > Good; I'll try to work on this idea in the weekend.
> >
> > So, we (me and Luca) managed to spend some more time on this and found a
> > few more things worth sharing. I'll try to summarize what we have got so
> > far (including what already discussed) because impression is that each
> > point might deserve a fix or at least consideration (just amazing how a
> > simple random fuzzer thing can highlight all that :).
>
> 1. Fuzzing finds bugs in any code. Always.
> If a code wasn't fuzzed, there are bugs.
>
> 2. This fuzzer is not so simple ;)
Indeed! I meant that it's amazing how the fuzzer was able to forge a
relatively simple reproducer that highlighted the problem.
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
Hi Dave, > Dave Stevenson hat am 26. Oktober 2018 um > 19:15 geschrieben: > > > Thanks Stefan. > I've picked up your latest patches which mean I can get the driver > loaded via the (almost) approved method. > I do seem to still have issues with not getting the expected address > ranges, so the driver/VPU was trying to map cached alias memory. As > your patches only came through yesterday I haven't had a chance to dig > through why yet. I've done a temporary hack to ensure we always map > the uncached alias, but that can't persist. does it mean with DT probing it worked before and with platform change it's broken? Or anything else cause this regression in 4.19? > The networking issue has been resolved :-) > > I've pushed where I've got to to > https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2b > It's a touch messy due to integrating in your patches in the last 24 > hours. It needs a full rebase so that my changes are on top of yours > rather than haphazard. > As we're moving to 4.19 fairly soon I may well abandon my 4.14 tree > and jump to either that or directly on staging. I'll see where I get > to early next week. Sorry, but there is no need for a quick shot against a downstream 4.14. I assumed you make your changes against upstream linux-next + Phil's and my patches. You can use https://github.com/anholt/linux/commits/bcm2835-audio until 4.20-rc1 is out. Using 4.14 or 4.19 doesn't make any sense to me. Regards Stefan > > Dave
Re: Oops in current tree in i2c
Hi Linus,
On 27-10-18 18:08, Linus Torvalds wrote:
Julian, Jiri,
On my laptop I'm getting a kernel page fault with the current git
tree, and I'm tentatively blaming commit
9ee3e06610fd ("HID: i2c-hid: override HID descriptors for certain devices")
but that's simply because it's the only thing that seems to touch this
particular area in this merge window.
The oops looks like this:
BUG: unable to handle kernel paging request at 7a25d598
PGD 0 P4D 0
Oops: [#1] SMP PTI
CPU: 1 PID: 888 Comm: systemd-udevd Not tainted 4.19.0-07715-g345671ea0f92 #4
Hardware name: Dell Inc. XPS 13 9350/09JHRY, BIOS 1.7.0 01/16/2018
RIP: 0010:strstr+0x19/0x70
where the code disassembly (and the register contents) shows that the
wild pointer is the first argument to "strstr()", which just has a
bogus value that is not a valid kernel pointer (RDI: 7a25d598
- which is obviously also the address of the page fault)
The call trace is:
dmi_matches+0x55/0xc0
dmi_first_match+0x26/0x40
i2c_hid_get_dmi_i2c_hid_desc_override+0x16/0x40 [i2c_hid]
i2c_hid_probe+0x28c/0x760 [i2c_hid]
i2c_device_probe+0x1e7/0x260
really_probe+0xf8/0x3e0
driver_probe_device+0x10f/0x120
bus_for_each_drv+0x66/0xb0
__device_attach+0xd9/0x150
bus_probe_device+0x8a/0xa0
device_add+0x48e/0x660
i2c_new_device+0x162/0x350
which is why I suspect that new i2c_hid_get_dmi_hid_report_desc_override() code.
I *think* the problem is that the i2c_hid_dmi_desc_override_table[]
isn't terminated by a NULL entry, and I will test that next.
Yes that likely is the problem. I already had a bug report from one of the
Manjaro maintainers who was cherry picking this into the Manjaro kernel.
So I ran some tests on a laptop of mine which does use i2c-hid but I
failed to reproduce the issue, so we both (me and the Manjaro maintainer)
both assumed something went wrong with the backport.
Both of us seem to have overlooked the missing terminating entry,
as well as other people involved in the patch.
What makes me *very* unhappy about this is that if I'm right, I think
it means that code was literally not tested at all by anybody who
didn't have one of the entries in that list.
That is not true, I've hit one of these unterminated dmi lists
issues before and it depends on what get put in mem directly
after the list by the linker, bugs caused by this do not always
reproduce unfortunately.
And as mentioned I have tested the patch on a machine with an i2c-hid
touchpad, which is not on the list and I did not hit this problem.
Anyways this is fixed now, thank you for catching this.
Regards,
Hans
Re: [PATCH] arch/x86/boot/memory.c: Touched up coding-style issues
* Jordan Borgner wrote:
> Added missing parentheses to sizeof() function in detect_memory_e820().
>
> Removed unnecessary braces in detect_memory_e801().
>
> Replaced three if-statements with a ternary if-statement and
> removed an unnecessary integer variable in detect_memory().
>
> This is my first patch I hope it is okay.
>
> Signed-off-by: Jordan Borgner
> ---
> linux-4.19/arch/x86/boot/memory.c | 24 +++-
> 1 file changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/linux-4.19/arch/x86/boot/memory.c
> b/linux-4.19/arch/x86/boot/memory.c
> index d9c28c8..a6124af 100644
> --- a/linux-4.19/arch/x86/boot/memory.c
> +++ b/linux-4.19/arch/x86/boot/memory.c
> @@ -26,7 +26,7 @@ static int detect_memory_e820(void)
>
> initregs();
> ireg.ax = 0xe820;
> - ireg.cx = sizeof buf;
> + ireg.cx = sizeof(buf);
> ireg.edx = SMAP;
> ireg.di = (size_t)
That's legit - could you do a single patch that only changes all the
'sizeof x' patterns in arch/x86/ to 'sizeof(x)']?
>
> @@ -88,11 +88,11 @@ static int detect_memory_e801(void)
> oreg.bx = oreg.dx;
> }
>
> - if (oreg.ax > 15*1024) {
> + if (oreg.ax > 15*1024)
> return -1; /* Bogus! */
> - } else if (oreg.ax == 15*1024) {
> + else if (oreg.ax == 15*1024)
> boot_params.alt_mem_k = (oreg.bx << 6) + oreg.ax;
> - } else {
> + else
> /*
>* This ignores memory above 16MB if we have a memory
>* hole there. If someone actually finds a machine
> @@ -101,7 +101,6 @@ static int detect_memory_e801(void)
>* map.
>*/
> boot_params.alt_mem_k = oreg.ax;
> - }
The original code was better - multi-screen-line statements require curly
braces in general.
>
> return 0;
> }
> @@ -121,16 +120,7 @@ static int detect_memory_88(void)
>
> int detect_memory(void)
> {
> - int err = -1;
> -
> - if (detect_memory_e820() > 0)
> - err = 0;
> -
> - if (!detect_memory_e801())
> - err = 0;
> -
> - if (!detect_memory_88())
> - err = 0;
> -
> - return err;
> + return (detect_memory_e820() > 0 ||
> + !detect_memory_e801()||
> + !detect_memory_88()) ? 0 : -1;
Here too I think the original flow of logic was easier to read - more
compact is not always better.
Also, please investigate whether the return value is actually *used*, and
if not then please send a separate patch that simplifies the code.
Thanks,
Ingo
Re: [Outreachy kernel] [RESEND PATCH 2/2] staging: vboxvideo: Use unsigned int instead bool
On Sun, 28 Oct 2018, Himanshu Jha wrote:
> On Sun, Oct 28, 2018 at 09:47:15AM +0100, Julia Lawall wrote:
> > > The "possible alignement issues" in CHECK report is difficult to figure
> > > out by just doing a glance analysis. :)
> > >
> > > Linus also suggested to use bool as the base type i.e., `bool x:1` but
> > > again sizeof(_Bool) is implementation defined ranging from 1-4 bytes.
> >
> > If bool x:1 has the size of bool, then wouldn't int x:1 have the size of
> > int? But my little experiments suggest that the size is the smallest that
> > fits the requested bits and alignment chosen by the compiler, regardless of
> > the type.
>
> Yes, correct!
> And we can't use sizeof on bitfields *directly*, nor reference it using a
> pointer.
>
> It can be applied only when these bitfields are wrapped in a structure.
>
> Testing:
>
> #include
> #include
>
> struct S {
> bool a:1;
> bool b:1;
> bool c:1;
> bool d:1;
> };
>
> int main(void)
> {
> printf("%zu\n", sizeof(struct S));
> }
>
> Output: 1
>
> If I change all bool to unsigned int, output is: *4*.
>
> So, conclusion is compiler doesn't squeeze the size less than
> native size of the datatype i.e., if we changed all members to
> unsigned int:1,
> total width = 4 bits
> padding = 4 bits
>
> Therefore, total size should have been = 1 byte!
> But since sizeof(unsigned int) == 4, it can't be squeezed to
> less than it.
This conclusion does not seem to be correct, if you try the following
program. I get 4 for everything, meaning that the four unsigned int bits
are getting squeezed into one byte when it is convenient.
#include
#include
struct S1 {
bool a:1;
bool b:1;
bool c:1;
bool d:1;
char a1;
char a2;
char a3;
};
struct S2 {
unsigned int a:1;
unsigned int b:1;
unsigned int c:1;
unsigned int d:1;
char a1;
char a2;
char a3;
};
int main(void)
{
printf("%zu\n", sizeof(struct S1));
printf("%zu\n", sizeof(struct S2));
printf("%zu\n", sizeof(unsigned int));
}
> Well, int x:1 can either have 0..1 or -1..0 range due implementation
> defined behavior as I said in the previous reply.
>
> If you really want to consider negative values, then make it explicit
> using `signed int x:1` which make range guaranteed to be -1..0
The code wants booleans, not negative values.
julia
Re: [PATCH v2 09/10] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver
Hi Lokesh, On Fri, 26 Oct 2018 21:19:41 +0100, Lokesh Vutla wrote: > > Hi Marc, > > [..snip..] > >> [...] > >> > > +/** > > + * ti_sci_inta_register_event() - Register a event to an interrupt > > aggregator > > + * @dev: Device pointer to source generating the event > > + * @src_id:TISCI device ID of the event source > > + * @src_index: Event source index within the device. > > + * @virq: Linux Virtual IRQ number > > + * @flags: Corresponding IRQ flags > > + * @ack_needed:If explicit clearing of event is required. > > + * > > + * Creates a new irq and attaches to IA domain if virq is not specified > > + * else attaches the event to vint corresponding to virq. > > + * When using TISCI within the client drivers, source indexes are > > always > > + * generated dynamically and cannot be represented in DT. So client > > + * drivers should call this API instead of platform_get_irq(). > > NAK. Either this fits in the standard model, or we adapt the standard > model to catter for your particular use case. But we don't define a new, > TI specific API. > > I have a hunch that if the IDs are generated dynamically, then the model > we use for MSIs would fit this thing. I also want to understand what > >>> > >>> hmm..I haven't thought about using MSI. Will try to explore it. But > >>> the "struct msi_msg" is not applicable in this case as device does not > >>> write to a specific location. > >> > >> It doesn't need to. You can perfectly ignore the address field and > >> only be concerned with the data. We already have MSI users that do not > >> need programming of the doorbell address, just the data. > > > > Just one more clarification. > > First let me explain the IRQ routes a bit deeply. As I said earlier > there are three ways in which IRQ can flow in AM65x SoC > 1) Device directly connected to GIC > - Device IRQ --> GIC > 2) Device connected to INTR. > - Device IRQ --> INTR --> GIC > 3) Devices connected to INTA. > - Device IRQ --> INTA --> INTR --> GIC > > 1 and 2 are straight forward and we use DT for IRQ > representation. Coming to 3 the trickier part is that Input to INTA > and output from INTA and dynamically managed. To be more specific: > - By hardware design there are certain set of physical global > events(interrupts) attached to an INTA. Out of which a certain range > are assigned to the current linux host that can be queried from > system-controller. > - Similarly out of all the INTA outputs(referenced as vints) a certain > range can be used by the current linux host. > > > So for configuring an IRQ route in case 3, the following steps are needed: > - Device id and device resource index for which the interrupt is needed THat is no different from a PCI device for example, where we need the requester ID and the number of the interrupt in the MSI-X table. > - A free event id from the range assigned to the INTA in this host context > - A free vint from the range assigned to the INTA in this host context > - A free gic IRQ from the range assigned to the INTR in this host context. >From what I understand of the driver, at least some of that is under the responsibility of the firmware, right? Or is the driver under control of all three parameters? To be honest, it doesn't really matter, as the as far as the kernel is concerned, the irqchip drivers are free to deal with the routing anyway they want. > With the above information, linux should send a message to > system-controller using TISCI protocol. After policing the given > information, system-controller does the following: > - Attaches the interrupt(INTA input) to the device resource index > - Muxes the interrupt(INTA input) to corresponding vint(INTA output) > - Muxes the vint(INTR input) to GIC irq(INTR output). Isn't there a 1:1 mapping between *used* INTR inputs and outputs? Since INTR is a router, there is no real muxing. I assume that the third point above is just a copy-paste error. > > For grouping of interrupts, the same vint number is to be passed to > system-controller for all the requests. > > Keeping all the above in mind, I see the following as software IRQ > Domain Hierarchy: > > 1) INTA multi MSI --> 2)INTA -->3) MSI --> 4) INTR -->5) GIC > > INTA driver has to set a chained IRQ using virq allocated from its > parent MSI. This is to differentiate the grouped interrupts within > INTA. > > Inorder to cover the above two MSI domains, a new bus driver has to be > created as I couldn't find a fit with the existing bus drivers. > > Does the above approach make sense? Please correct me if i am wrong. I think this can be further simplified, as you seem to assume that dynamic allocation implies MSI. This is not the case. You can perfectly use dynamically allocated interrupts and still not use MSIs. INTA is indeed a chained interrupt controller, as it may mux several inputs
Re: [PATCH v2 3/5] Creates macro to avoid variable shadowing
On Tue, Oct 23, 2018 at 10:11 AM Leonardo Brás wrote:
>
> Creates DEF_FIELD_ADDR_VAR as a more generic version of the DEF_FIELD_ADD
> macro, allowing usage of a variable name other than the struct element name.
> Also, sets DEF_FIELD_ADDR as a specific usage of DEF_FILD_ADDR_VAR in which
> the var name is the same as the struct element name.
>
> Signed-off-by: Leonardo Brás
> ---
Applied to linux-kbuild.
> scripts/mod/file2alias.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> index 7be43697ff84..3015c0bdecb2 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -95,12 +95,20 @@ extern struct devtable *__start___devtable[],
> *__stop___devtable[];
> */
> #define DEF_FIELD(m, devid, f) \
> typeof(((struct devid *)0)->f) f = TO_NATIVE(*(typeof(f) *)((m) +
> OFF_##devid##_##f))
> +
> +/* Define a variable v that holds the address of field f of struct devid
> + * based at address m. Due to the way typeof works, for a field of type
> + * T[N] the variable has type T(*)[N], _not_ T*.
> + */
> +#define DEF_FIELD_ADDR_VAR(m, devid, f, v) \
> + typeof(((struct devid *)0)->f) *v = ((m) + OFF_##devid##_##f)
> +
> /* Define a variable f that holds the address of field f of struct devid
> * based at address m. Due to the way typeof works, for a field of type
> * T[N] the variable has type T(*)[N], _not_ T*.
> */
> #define DEF_FIELD_ADDR(m, devid, f) \
> - typeof(((struct devid *)0)->f) *f = ((m) + OFF_##devid##_##f)
> + DEF_FIELD_ADDR_VAR(m, devid, f, f)
>
> /* Add a table entry. We test function type matches while we're here. */
> #define ADD_TO_DEVTABLE(device_id, type, function) \
> @@ -641,25 +649,27 @@ static void do_pnp_card_entries(void *symval, unsigned
> long size,
> unsigned int i;
>
> device_id_check(mod->name, "pnp", size, id_size, symval);
> + DEF_FIELD_ADDR(symval, pnp_card_device_id, devs);
> + typeof(devs) devs_last;
>
> for (i = 0; i < count; i++) {
> unsigned int j;
> - DEF_FIELD_ADDR(symval + i*id_size, pnp_card_device_id, devs);
> + devs_last = devs + i * id_size;
>
> for (j = 0; j < PNP_MAX_DEVICES; j++) {
> - const char *id = (char *)(*devs)[j].id;
> - int i2, j2;
> + const char *id = (char *)(*devs_last)[j].id;
> + int j2;
> int dup = 0;
>
> if (!id[0])
> break;
>
> /* find duplicate, already added value */
> - for (i2 = 0; i2 < i && !dup; i2++) {
> - DEF_FIELD_ADDR(symval + i2*id_size,
> pnp_card_device_id, devs);
> + while ((devs_last -= id_size) >= devs && !dup) {
>
> for (j2 = 0; j2 < PNP_MAX_DEVICES; j2++) {
> - const char *id2 = (char
> *)(*devs)[j2].id;
> + const char *id2 =
> + (char *)(*devs_last)[j2].id;
>
> if (!id2[0])
> break;
> --
> 2.19.1
>
--
Best Regards
Masahiro Yamada
Re: [regression, bisected] Keyboard not responding after resuming from suspend/hibernate
Thu, 25 Oct 2018 09:49:03 +0200 tarihinde Pavel Machek yazdı: > Hi! > > Here's problem bisected down to: > > commit 9d659ae14b545c4296e812c70493bfdc999b5c1c > Author: Peter Zijlstra > Date: Tue Aug 23 14:40:16 2016 +0200 > > locking/mutex: Add lock handoff to avoid starvation > > Implement lock handoff to avoid lock starvation. > > Numan, I assume revert of that patch on the 4.18 kernel still makes it > work? > Unfortunately, I could not revert 9d659ae14b545c4296e812c70493bfdc999b5c1c on kernels from 4.18.16 to 4.10-rc1 because there were too much conflicts, which I could not solve as an "average Joe". I tried a3ea3d9b865c2a8f7fe455c7fa26db4b6fd066e3 which is parent of 9d659ae14b545c4296e812c70493bfdc999b5c1c and succeeded to compile kernel. git checkout a3ea3d9b865c2a8f7fe455c7fa26db4b6fd066e3 Then, I compiled kernel and rebooted with it. I tried a couples of times suspending and resuming, all of the time keyboard worked as expected. uname -a Linux ubuntu 4.9.0-rc2reverted+ #1 SMP Sun Oct 28 20:29:39 +03 2018 x86_64 x86_64 x86_64 GNU/Linux awk -f ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux ubuntu 4.9.0-rc2reverted+ #1 SMP Sun Oct 28 20:29:39 +03 2018 x86_64 x86_64 x86_64 GNU/Linux GNU Make4.1 Binutils2.30 Util-linux 2.31.1 Mount 2.31.1 Module-init-tools 24 E2fsprogs 1.44.1 Pcmciautils 018 Linux C Library 2.27 Dynamic linker (ldd)2.27 Linux C++ Library 6.0.25 Procps 3.3.12 Kbd 2.0.4 Console-tools 2.0.4 Sh-utils8.28 Udev237 Wireless-tools 30 Modules Loaded ahci arc4 ath ath9k ath9k_common ath9k_hw autofs4 binfmt_misc ccm cfg80211 coretemp crc32_pclmul crct10dif_pclmul cryptd drm drm_kms_helper fb_sys_fops fjes ghash_clmulni_intel hid hid_generic i2c_algo_bit i915 input_leds intel_cstate intel_powerclamp intel_rapl intel_rapl_perf ip6table_filter ip6_tables ip6t_REJECT ip6t_rt iptable_filter ip_tables ipt_REJECT irqbypass kvm kvm_intel libahci lpc_ich mac80211 mac_hid mei mei_me nf_conntrack nf_conntrack_broadcast nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack_ipv6 nf_conntrack_netbios_ns nf_defrag_ipv4 nf_defrag_ipv6 nf_log_common nf_log_ipv4 nf_log_ipv6 nf_nat nf_nat_ftp nf_reject_ipv4 nf_reject_ipv6 psmouse sch_fq_codel serio_raw shpchp snd snd_hda_codec snd_hda_codec_conexant snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_core snd_hda_intel snd_hwdep snd_pcm snd_rawmidi snd_seq snd_seq_device snd_seq_midi snd_seq_midi_event snd_timer sony_laptop soundcore syscopyarea sysfillrect sysimgblt usbhid video x86_pkg_temp_thermal x_tables xt_addrtype xt_conntrack xt_hl xt_limit xt_LOG xt_tcpudp dmesg | grep i8042 [2.986695] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [2.989921] serio: i8042 KBD port at 0x60,0x64 irq 1 [2.989925] serio: i8042 AUX port at 0x60,0x64 irq 12 [3.014179] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 [ 20.297566] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input8 > Peter, any ideas? > > Pavel > > On Fri 2018-10-19 10:20:31, Numan Demirdöğen wrote: > > On Fri, 31 Aug 2018 21:53:11 +0300 > > Numan Demirdöğen wrote: > > > > >If I put laptop to suspend or hibernate by closing lid, power > > >manager or any other method and then I resume/wake up laptop, > > >keyboard is not responding. My laptop is a Sony Vaio VPCEH2F1E. > > > > > >Steps to produce bug: > > >1. Boot > > >2. Put laptop to sleep > > >3. Resume > > > > > >What I expect to happen: Keyboard responds to key press. > > >What happens: Keyboard does not respond but mouse and trackball are > > >working. > > > > > >git bisect point 9d659ae14b545c4296e812c70493bfdc999b5c1c as the > > >first bad commit. > > > > > >Bad commit link: > > >https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=9d659ae14b545c4296e812c70493bfdc999b5c1c > > > > > > Link to actual bug report: > > >https://bugzilla.kernel.org/show_bug.cgi?id=195471 > > > > > >awk -f ver_linux > > >Linux korsan 4.18.5-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 24 12:48:58 > > >UTC 2018 x86_64 GNU/Linux GNU C8.2.0 > > >GNU Make 4.2.1 > > >Binutils 2.31.1 > > >Util-linux 2.32.1 > > >Mount 2.32.1 > > >Module-init-tools 25 > > >E2fsprogs 1.44.4 > > >Jfsutils 1.1.15 > > >Reiserfsprogs 3.6.27 > > >Xfsprogs 4.17.0 > > >Pcmciautils018 > > >Linux C Library2.28 > > >Dynamic linker (ldd) 2.28 > > >Linux C++ Library 6.0.25 > > >Procps
Re: [GIT PULL] kselftest update for Linux 4.20-rc1
On Thu, Oct 25, 2018 at 11:36 AM Shuah Khan wrote: > > Please pull the following kselftest update for Linux 4.20-rc1 Pulled, Linus
Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
On Sat, Oct 27 2018, Josh Triplett wrote: > On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote: >> On Wed, Oct 24 2018, Josh Triplett wrote: >> >> > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote: >> >> On Sun, Oct 21 2018, Josh Triplett wrote: >> >> >> >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote: >> >> >> I call on you, Greg: >> >> >> - to abandon this divisive attempt to impose a "Code of Conduct" >> >> >> - to revert 8a104f8b5867c68 >> >> >> - to return to your core competence of building a great team around >> >> >>a great kernel >> >> >> >> >> >> #Isupportreversion >> >> >> >> >> >> I call on the community to consider what *does* need to be said, about >> >> >> conduct, to people outside the community and who have recently joined. >> >> >> What is the document that you would have liked to have read as you were >> >> >> starting out? It is all too long ago for me to remember clearly, and >> >> >> so >> >> >> much has changed. >> >> > >> >> > The document I would have liked to have read when starting out is >> >> > currently checked into the source tree in >> >> > Documentation/process/code-of-conduct.rst . >> >> >> >> I'm curious - what would you have gained by reading that document? >> > >> > I would have then had rather less of a pervasive feeling of "if I make >> > even a single mistake I get made an example of in ways that will feed >> > people's quotes files for years to come". >> >> Thanks for your reply. Certainly feeling safe is important, and having >> clear statements that the community values and promotes psychological >> safety is valuable. >> >> The old "code of conflict" said >>If however, anyone feels personally abused, threatened, or otherwise >>uncomfortable due to this process, that is not acceptable. >> >> would you have not found this a strong enough statement to ward off that >> pervasive feeling? > > Not when that document started out effectively saying, in an elaborate > way, "code > people". (Leaving aside that the more important detail > would be the community actually acting consistently with the code of > conduct it espoused.) I certainly cannot argue with that. that those starting words have been preserved in the code-of-conduct-interpretation.rst, so we still have them. > >> In the current code, would The "Our Pledge" section have been >> sufficient, or do you think the other sections would have actually >> helped you? > > "Our Standards" would have been at least as important to me personally, > as would "Enforcement" (and more importantly, examples of that applying > in practice and not just as empty words). I find it interesting that you appear to particularly value the Enforcement section, I particularly dislike it. It is also interesting that you seem to fear that it might be "empty words", and elsewhere in this thread Laura Abbott wondered Will those problems actually be handled appropriately when the time comes? I can't actually say for sure She goes on to opine that trust is needed, but if we really had trust, we might not need the code. None of us, to my knowledge, has credible expertise or demonstrated experience in this area, so we might easily become the blind misleading the blind. However I would like to make one more attempt to give context and meaning to my dislike for that section. The approach described seem to be combative rather than conciliatory. The first action-step described is to mark a report - to complain. This isn't quite as bad as being litigious, but it seems headed in that direction. I would rather we gave people the power to resolve their own issues, rather than an avenue to magnify them but involving others. Think for a moment about how we resolve technical differences. I acknowledge that we don't always resolve them very well, but when we do - what techniques seem to work? We don't have any court to which we can apply to resolve our differences, we need to present our case and garner support from like-minded people. To help with that, we do have some standards like "no regressions" and "maintainable" and various coding-style guidelines. They don't necessarily answer everything but they help. Over all this, there is a general principle that the person who writes the code makes the decisions - "code talks". The person who puts in the effort gets heard more than the person who complains from the side lines. This isn't all perfect, but it largely works, and we are familiar with it. Can we translate any of that experience to the social/harm side of things? 1/ We can have some standards. We will never all agree on the level of detail needed (but then, we don't all agree on checkpatch.pl either), but anything generally in the right direction would help (I like "Be helpful. Don't be harmful". "Be kind to each other" is in the interpretation). 2/ We can voice our support when we see a cause the we agree with, whether it is a revised API, or
CONTACT HIM NOW
Attn: My Dear I am glad to inform you that i have successfully concluded the transaction which i seek for your family help before, Now the fund has been transferred to Hong Kong through the assistant of Mr.Wong Lee, who is a business man base in Hong Kong.Once again, I have mapped out a compensation fund and wrote on your favor a certified bank draft $2.5Million; I left the bank draft with a shipping office on my departure to Hong Kong.Kindly contact Hilla Ager, with below information and instruct Hilla Ager where to deliver the certified bank draft to you. Name: Hilla Ager Email: hill_...@yahoo.dk As soon as you receive the certified bank draft, you should let me know because i am busy here trying to put things together and may not be chanced to email you frequently,feel free to contact Hilla Ager, for the certified bank draft. Thanks and remain blessed. Mr. Larry Johnson
w1: coding style and checkpatch fixes
Hi, This is my first series of patches for the Linux kernel. I started by familiarizing myself with coding style and satisfying my inner OCD by cleaning the 1-wire subsystem. Steffen
[PATCH 6/9] w1: do not log errors about failed memory allocations
This fixes a warning raised by the checkpatch tool.
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 7 +--
drivers/w1/w1_int.c | 6 +-
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index bad2ee26cd4e..e8ce97e066ec 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -747,13 +747,8 @@ int w1_attach_slave_device(struct w1_master *dev, struct
w1_reg_num *rn)
struct w1_netlink_msg msg;
sl = kzalloc(sizeof(struct w1_slave), GFP_KERNEL);
- if (!sl) {
- dev_err(>dev,
-"%s: failed to allocate new slave device.\n",
-__func__);
+ if (!sl)
return -ENOMEM;
- }
-
sl->owner = THIS_MODULE;
sl->master = dev;
diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
index 72b9392d9551..dd34d6a33f50 100644
--- a/drivers/w1/w1_int.c
+++ b/drivers/w1/w1_int.c
@@ -33,12 +33,8 @@ static struct w1_master *w1_alloc_dev(u32 id, int
slave_count, int slave_ttl,
*/
dev = kzalloc(sizeof(struct w1_master) +
sizeof(struct w1_bus_master), GFP_KERNEL);
- if (!dev) {
- pr_err("Failed to allocate %zd bytes for new w1 device.\n",
- sizeof(struct w1_master));
+ if (!dev)
return NULL;
- }
-
dev->bus_master = (struct w1_bus_master *)(dev + 1);
--
2.11.0
[PATCH 3/9] w1: add newlines after declarations
This satisfies a checkpatch warning
Signed-off-by: Steffen Vogel
---
drivers/w1/w1.c | 23 +++
drivers/w1/w1_netlink.c | 7 +++
2 files changed, 30 insertions(+)
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index bd95dfe4041d..812186ce35d6 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -130,6 +130,7 @@ static ssize_t rw_write(struct file *filp, struct kobject
*kobj,
out_up:
mutex_unlock(>master->mutex);
+
return count;
}
@@ -142,6 +143,7 @@ static ssize_t rw_read(struct file *filp, struct kobject
*kobj,
mutex_lock(>master->mutex);
w1_read_block(sl->master, buf, count);
mutex_unlock(>master->mutex);
+
return count;
}
@@ -297,6 +299,7 @@ static ssize_t w1_master_attribute_show_pointer(struct
device *dev,
mutex_lock(>mutex);
count = sprintf(buf, "0x%p\n", md->bus_master);
mutex_unlock(>mutex);
+
return count;
}
@@ -304,7 +307,9 @@ static ssize_t w1_master_attribute_show_timeout(struct
device *dev,
struct device_attribute *attr, char *buf)
{
ssize_t count;
+
count = sprintf(buf, "%d\n", w1_timeout);
+
return count;
}
@@ -312,7 +317,9 @@ static ssize_t w1_master_attribute_show_timeout_us(struct
device *dev,
struct device_attribute *attr, char *buf)
{
ssize_t count;
+
count = sprintf(buf, "%d\n", w1_timeout_us);
+
return count;
}
@@ -369,6 +376,7 @@ static ssize_t w1_master_attribute_show_slave_count(struct
device *dev,
mutex_lock(>mutex);
count = sprintf(buf, "%d\n", md->slave_count);
mutex_unlock(>mutex);
+
return count;
}
@@ -399,8 +407,10 @@ static ssize_t w1_master_attribute_show_add(struct device
*dev,
struct device_attribute *attr, char *buf)
{
int c = PAGE_SIZE;
+
c -= snprintf(buf+PAGE_SIZE - c, c,
"write device id xx- to add slave\n");
+
return PAGE_SIZE - c;
}
@@ -449,6 +459,7 @@ struct w1_slave *w1_slave_search_device(struct w1_master
*dev,
struct w1_reg_num *rn)
{
struct w1_slave *sl;
+
mutex_lock(>list_mutex);
list_for_each_entry(sl, >slist, w1_slave_entry) {
if (sl->reg_num.family == rn->family &&
@@ -459,6 +470,7 @@ struct w1_slave *w1_slave_search_device(struct w1_master
*dev,
}
}
mutex_unlock(>list_mutex);
+
return NULL;
}
@@ -495,8 +507,10 @@ static ssize_t w1_master_attribute_show_remove(struct
device *dev,
struct device_attribute *attr, char *buf)
{
int c = PAGE_SIZE;
+
c -= snprintf(buf+PAGE_SIZE - c, c,
"write device id xx- to remove slave\n");
+
return PAGE_SIZE - c;
}
@@ -674,6 +688,7 @@ static int w1_family_notify(unsigned long action, struct
w1_slave *sl)
sysfs_remove_groups(>dev.kobj, fops->groups);
break;
}
+
return 0;
}
@@ -709,6 +724,7 @@ static int __w1_attach_slave_device(struct w1_slave *sl)
"Device registration [%s] failed. err=%d\n",
dev_name(>dev), err);
put_device(>dev);
+
return err;
}
w1_family_notify(BUS_NOTIFY_ADD_DEVICE, sl);
@@ -777,6 +793,7 @@ int w1_attach_slave_device(struct w1_master *dev, struct
w1_reg_num *rn)
w1_family_put(sl->family);
atomic_dec(>master->refcnt);
kfree(sl);
+
return err;
}
@@ -793,6 +810,7 @@ int w1_unref_slave(struct w1_slave *sl)
{
struct w1_master *dev = sl->master;
int refcnt;
+
mutex_lock(>list_mutex);
refcnt = atomic_sub_return(1, >refcnt);
if (refcnt == 0) {
@@ -817,6 +835,7 @@ int w1_unref_slave(struct w1_slave *sl)
}
atomic_dec(>refcnt);
mutex_unlock(>list_mutex);
+
return refcnt;
}
@@ -824,6 +843,7 @@ int w1_slave_detach(struct w1_slave *sl)
{
/* Only detach a slave once as it decreases the refcnt each time. */
int destroy_now;
+
mutex_lock(>master->list_mutex);
destroy_now = !test_bit(W1_SLAVE_DETACH, >flags);
set_bit(W1_SLAVE_DETACH, >flags);
@@ -831,6 +851,7 @@ int w1_slave_detach(struct w1_slave *sl)
if (destroy_now)
destroy_now = !w1_unref_slave(sl);
+
return destroy_now ? 0 : -EBUSY;
}
@@ -996,6 +1017,7 @@ void w1_search(struct w1_master *dev, u8 search_type,
/* Do fast search on single slave bus */
if (dev->max_slave_count == 1) {
int rv;
+
w1_write_8(dev, W1_READ_ROM);
rv = w1_read_block(dev, (u8 *), 8);
mutex_unlock(>bus_mutex);
@@ -1127,6 +1149,7 @@ int w1_process_callbacks(struct w1_master *dev)
mutex_lock(>list_mutex);
Re: [PATCH v2 0/2] i2c-omap: Enable i2c-omap driver for AM654 SoCs
On Sat, Oct 20, 2018 at 01:23:40PM +0530, Vignesh R wrote: > > > On 28-Sep-18 10:55 AM, Vignesh R wrote: > > Couple of patches to enable i2c-omap driver to be used with TI's new > > AM654 platforms. > > > > > > Vignesh R (2): > > dt-bindings: i2c-omap: Add new compatible for AM654 SoCs > > i2c: busses: Kconfig: Enable I2C_OMAP for ARCH_K3 > > > > Documentation/devicetree/bindings/i2c/i2c-omap.txt | 8 ++-- > > drivers/i2c/busses/Kconfig | 2 +- > > 2 files changed, 7 insertions(+), 3 deletions(-) > > > > Gentle ping... Maintainer tags are missing. Tony is listed for this driver on OMAP2+. Is this his realm? Do we need a specific maintainer for this driver? signature.asc Description: PGP signature
linux-next: build failure in Linus' tree
Hi Linus,
After merging the origin tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
net/bridge/br_multicast.c: In function 'br_multicast_query_received':
net/bridge/br_multicast.c:1432:32: error: 'union ' has no member
named 'ip6'; did you mean 'ip4'?
!ipv6_addr_any(>u.ip6)))
^~~
ip4
Caused by commit
5a2de63fd1a5 ("bridge: do not add port to router list when receives query
with source 0.0.0.0")
# CONFIG_IPV6 is not set
I have just reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpIyOROMPVgY.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure in Linus' tree
On Sun, Oct 28, 2018 at 3:35 PM Stephen Rothwell wrote:
>
> After merging the origin tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
linux-next is back! Wheee..
> 5a2de63fd1a5 ("bridge: do not add port to router list when receives query
> with source 0.0.0.0")
David?
Linus
linux-next: build failure in Linus' tree
Hi Linus,
After merging the origin tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: 'struct iphdr'
declared inside parameter list will not be visible outside of this definition
or declaration
struct iphdr *iph)
^
drivers/net/ethernet/mellanox/mlx4/en_rx.c: In function 'get_fixed_ipv4_csum':
drivers/net/ethernet/mellanox/mlx4/en_rx.c:586:20: error: dereferencing pointer
to incomplete type 'struct iphdr'
__u8 ipproto = iph->protocol;
^~
Caused by commit
55469bc6b577 ("drivers: net: remove inclusion when not
needed")
I added the following patch:
From: Stephen Rothwell
Date: Mon, 29 Oct 2018 09:40:39 +1100
Subject: [PATCH] drivers: net: include linux/ip.h for iphdr
Fixes: 55469bc6b577 ("drivers: net: remove inclusion when not
needed")
Cc: Eric Dumazet
Cc: David S. Miller
Signed-off-by: Stephen Rothwell
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 5a6d0919533d..ffa54767dfe5 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -31,6 +31,7 @@
*
*/
+#include
#include
#include
#include
--
2.18.0
--
Cheers,
Stephen Rothwell
pgphzHJlGV24X.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/9] w1: improve coding style by following strict 80 column line limit
On Sun, 2018-10-28 at 23:09 +0100, Steffen Vogel wrote:
> This satisfies a checkpatch warning
Perhaps run your patches through checkpatch with --strict
> diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
[]
> @@ -85,7 +85,8 @@ static void w1_slave_release(struct device *dev)
> sl->master->slave_count--;
> }
>
> -static ssize_t name_show(struct device *dev, struct device_attribute *attr,
> char *buf)
> +static ssize_t name_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
atypical alignment.
> []
> @@ -170,7 +173,9 @@ static void w1_netlink_queue_status(struct w1_cb_block
> *block,
> block->msg->len = 0;
> block->msg->status = (u8)-error;
> if (req_cmd) {
> - struct w1_netlink_cmd *cmd = (struct w1_netlink_cmd
> *)block->msg->data;
> + struct w1_netlink_cmd *cmd =
> + (struct w1_netlink_cmd *) block->msg->data;
unnecessary space after cast
Re: [PATCH] fpga: altera_cvp: restrict registration to CvP enabled devices
Hi Andreas, On Thu, Oct 25, 2018 at 08:44:06AM +, Andreas Puhm wrote: > >My experience with cvp is with Arria10 and Stratix 10. The PCIe Hard IP > >gets configured when the IOring gets configured at power on. The idea is > >that the load of the IOring is very fast, much before the infamous 100ms > >PCIe timeout for link training. When the Hard IP is configured, the > >CVP_EN is set or cleared according to how it was configured. Yes, you > > So is it correct that the value of CVP_EN can be evaluated by the altera_cvp > right in the first call of its probe function > (as would be the case with my proposed patch). > > If it is, I will fix the remaining issues with the patch and submit it. Yes please, go ahead and fix up the remaining issues (+ send it using git send-email) Thanks, Moritz
Re: [PATCH 0/2] tracing: Fix synthetic event parser
On 10/28/2018 02:01 AM, Steven Rostedt wrote: > On Mon, 22 Oct 2018 00:07:50 +0900 > Masami Hiramatsu wrote: > >> Hi, >> >> I found another bug in synthetic event. This is a small fix, but >> confusingly, there is also a bug in a test case. >> >> Steve, since the testcase bugfix ([2/2]) breaks the test result >> unless corresponding fix ([1/2]), I would like to ask you to send >> these fixes from your tree. > > Hi Masami, > > I'm currently in travel mode, but I'm letting you know that I'll be > working on these today. It might take a bit to get out. > > I'll add them on top of my linux-next code, and include them in the > pull request I'm hoping to do on Tuesday. > > -- Steve > Hi Steve, Are there any dependencies on my pull request I sent to Linus? It hasn't been pulled in yet. If there is one, could please you mention that in your pull request for this. thanks, -- Shuah
Re: Logitech high-resolution scrolling..
On Sun, Oct 28, 2018 at 12:13 PM Linus Torvalds
wrote:
>
> So the recent change to enable the high-res scrolling really seems a
> bit *too* extreme.
>
> Is there some middle ground that turns the mouse from "look at it
> sideways and it starts scrolling" to something slightly more
> reasonable?
Actually, I think the bug may be in the generic HID high-resolution
scrolling code, and I only notice because the Logitech support means
that now I see it.
In particular, if you look at hid_scroll_counter_handle_scroll(),
you'll notice that it tries to turn a high-res scroll event into a
regular wheel event by using the resolution_multiplier.
But that code looks really broken. It tries to react to a "half
multiplier" thing:
int threshold = counter->resolution_multiplier / 2;
..
counter->remainder += hi_res_value;
if (abs(counter->remainder) >= threshold) {
and that's absolutely and entirely wrong.
Imagine that the high-res wheel counter has just moved a bit up (by
one high-res) tick, so now it's at the half-way mark to the
resolution_multiplier, and we scroll up by one:
low_res_scroll_amount =
counter->remainder / counter->resolution_multiplier
+ (hi_res_value > 0 ? 1 : -1);
input_report_rel(counter->dev, REL_WHEEL,
low_res_scroll_amount);
and then correct for it:
counter->remainder -=
low_res_scroll_amount * counter->resolution_multiplier;
now we went from "half resolution multiplier positive" to "half negative".
Which means that next time that the high-res event happens by even
just one high-resolution tick in the other direction, we'll now
generate a low-resolution scroll event in the other direction.
In other words, that function results in unstable behavior. Tiny tiny
movements back-and-forth in the high-res wheel events (which could be
just because either the sensor is unstable, or the wheel is wiggling
imperceptibly) can result in visible movement in the low-res
("regular") wheel reporting.
There is no "damping" function, in other words. Noise in the high
resolution reading can result in noise in the regular wheel reporting.
So that threshold handling needs to be fixed, I feel. Either get rid
of it entirely (you need to scroll a *full* resolution_multiplier to
get a regular wheel event), or the counter->remainder needs to be
*cleared* when a wheel event has been sent so that you don't get into
the whole "back-and-forth" mode.
Or some other damping model. I suspect there are people who have
researched what the right answer is, but I guarantee that the current
code is not the right answer.
I suspect this also explains why I *sometimes* see that "just moving
the mouse sends wheel events", and at other times don't. It needs to
get close to that "half a resolution multiplier" stage to get into the
bad cases, but then tiny tiny perturbations can cause unstable
behavior.
I can't be the only person seeing this, but I guess the Logitech mouse
is right now the only one that uses the new generic HID code, and I
guess not a lot of people have been *using* it.
Harry?
Linus
Re: [Ksummit-discuss] The linux devs can rescind their license grant.
On Sun, Oct 28 2018, Jiri Kosina wrote: > On Sat, 27 Oct 2018, tim.b...@sony.com wrote: > >> Al, >> >> Can you please, even in the face of comments you find irritating, keep >> your responses more civil? Calling someone a "wankstain" is >> unprofessional > > Tim, > > to be completely honest, communicating anonymously doesn't really match my > "this is highly professional" standards either, so I don't think we should > be losing too much sleep over this particular e-mail exchange. I agree with Tim here. It doesn't really matter who (or what) you are talking to, what matters is the context in which you are talking. We seem to be trying to raise the standard of communication within the kernel community. That means all communication. > > CoC explicitly requires us to be reasonably nice to the human being on the > other end of the wire, which I whole-heartedly believe is a very noble and > nice goal. But you really have to know at least a little bit who's there > on the other end. Otherwise failure to communicate might be sort of > inevitable. As you know, I think the CoC is a mistake and should be removed. But seeing you to play that game: 1/ code-of-conduct.rst doesn't contain the word "human" at all 2/ code-of-conduect-interpretation.rst explicitly says We know everyone is human which could be read as implying that you need to treat the other person as human, even if they don't act that way. Do you *really* want to use the CoC to support your position? Thanks, NeilBrown > > -- > Jiri Kosina > SUSE Labs signature.asc Description: PGP signature
XFS: Hang and dmesg flood on mounting invalid FS image
Hello, When mounting a broken XFS image, the kernel hangs and floods dmesg with stack traces. How to reproduce with kvm-xfstests: 1) Checkout v4.19, copy x86_64-config-4.14 to .config, `make olddefconfig` and compile 2) Unpack the attached image (128 Mb uncompressed) to /tmp/kvm-xfstests-$USER 3) Inside the `kvm-xfstests shell`: root@kvm-xfstests:~# mount /vtmp root@kvm-xfstests:~# mount /vtmp/xfs.img /mnt [ 39.280840] XFS (loop0): Mounting V5 Filesystem [ 39.303657] XFS (loop0): Internal error xlog_valid_rec_header(2) at line 5283 of file fs/xfs/xfs_log_recover.c. Caller xlog_do_recovery_pass+0x2bd/0x5d0 [ 39.304886] CPU: 0 PID: 373 Comm: mount Not tainted 4.19.0-xfstests #1 [ 39.305491] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1ubuntu1 04/01/2014 [ 39.306247] Call Trace: [ 39.306464] dump_stack+0x85/0xc0 [ 39.306751] xlog_valid_rec_header.isra.6+0xd5/0xe0 [ 39.307250] xlog_do_recovery_pass+0x2bd/0x5d0 [ 39.307624] ? xlog_bread_noalign+0x98/0x110 [ 39.307983] ? xlog_bread_noalign+0x98/0x110 [ 39.308344] xlog_verify_head+0xab/0x190 [ 39.308675] xlog_find_tail+0x208/0x350 [ 39.308999] xlog_recover+0x2b/0x160 [ 39.309307] xfs_log_mount+0x280/0x2a0 [ 39.309625] xfs_mountfs+0x42f/0x890 [ 39.309928] ? xfs_mru_cache_create+0x18b/0x1f0 [ 39.310309] xfs_fs_fill_super+0x4f8/0x6d0 [ 39.310655] ? xfs_test_remount_options+0x60/0x60 [ 39.311050] mount_bdev+0x17f/0x1b0 [ 39.311347] mount_fs+0x3b/0x170 [ 39.311624] ? __init_waitqueue_head+0x36/0x50 [ 39.311999] vfs_kern_mount.part.16+0x54/0x160 [ 39.312374] do_mount+0x20e/0xdf0 [ 39.312657] ? memdup_user+0x3e/0x70 [ 39.312961] __ia32_compat_sys_mount+0xa3/0x140 [ 39.313346] do_fast_syscall_32+0x9d/0x2f0 [ 39.313694] entry_SYSENTER_compat+0x84/0x96 [ 39.314126] XFS (loop0): Torn write (CRC failure) detected at log block 0xaaf. Truncating head block from 0xab7. [ 39.316912] XFS (loop0): Internal error xlog_valid_rec_header(2) at line 5283 of file fs/xfs/xfs_log_recover.c. Caller xlog_do_recovery_pass+0x2bd/0x5d0 [ 39.318057] CPU: 0 PID: 373 Comm: mount Not tainted 4.19.0-xfstests #1 [ 39.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1ubuntu1 04/01/2014 [ 39.319339] Call Trace: [ 39.319552] dump_stack+0x85/0xc0 [ 39.319834] xlog_valid_rec_header.isra.6+0xd5/0xe0 [ 39.320244] xlog_do_recovery_pass+0x2bd/0x5d0 [ 39.320618] ? xlog_bread_noalign+0x98/0x110 [ 39.320979] ? xlog_bread_noalign+0x98/0x110 [ 39.321344] xlog_verify_tail+0x144/0x1e0 [ 39.321686] xlog_verify_head+0xd4/0x190 [ 39.322021] xlog_find_tail+0x208/0x350 [ 39.322348] xlog_recover+0x2b/0x160 [ 39.322654] xfs_log_mount+0x280/0x2a0 [ 39.322974] xfs_mountfs+0x42f/0x890 [ 39.323280] ? xfs_mru_cache_create+0x18b/0x1f0 [ 39.323664] xfs_fs_fill_super+0x4f8/0x6d0 [ 39.324013] ? xfs_test_remount_options+0x60/0x60 [ 39.324411] mount_bdev+0x17f/0x1b0 [ 39.324710] mount_fs+0x3b/0x170 [ 39.324988] ? __init_waitqueue_head+0x36/0x50 [ 39.325369] vfs_kern_mount.part.16+0x54/0x160 [ 39.325747] do_mount+0x20e/0xdf0 [ 39.326063] ? memdup_user+0x3e/0x70 [ 39.326369] __ia32_compat_sys_mount+0xa3/0x140 [ 39.326753] do_fast_syscall_32+0x9d/0x2f0 [ 39.327101] entry_SYSENTER_compat+0x84/0x96 [ 39.328873] XFS (loop0): Internal error xlog_valid_rec_header(2) at line 5283 of file fs/xfs/xfs_log_recover.c. Caller xlog_do_recovery_pass+0x2bd/0x5d0 [ 39.330024] CPU: 0 PID: 373 Comm: mount Not tainted 4.19.0-xfstests #1 [ 39.330574] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1ubuntu1 04/01/2014 [ 39.331349] Call Trace: [ 39.331565] dump_stack+0x85/0xc0 [ 39.331850] xlog_valid_rec_header.isra.6+0xd5/0xe0 [ 39.332264] xlog_do_recovery_pass+0x2bd/0x5d0 [ 39.332642] ? xlog_bread_noalign+0x98/0x110 [ 39.333005] ? xlog_bread_noalign+0x98/0x110 [ 39.71] xlog_verify_tail+0x144/0x1e0 [ 39.333713] xlog_verify_head+0xd4/0x190 [ 39.334048] xlog_find_tail+0x208/0x350 [ 39.334376] xlog_recover+0x2b/0x160 [ 39.334682] xfs_log_mount+0x280/0x2a0 [ 39.335003] xfs_mountfs+0x42f/0x890 [ 39.335309] ? xfs_mru_cache_create+0x18b/0x1f0 [ 39.335693] xfs_fs_fill_super+0x4f8/0x6d0 [ 39.336041] ? xfs_test_remount_options+0x60/0x60 [ 39.336439] mount_bdev+0x17f/0x1b0 [ 39.336739] mount_fs+0x3b/0x170 [ 39.337016] ? __init_waitqueue_head+0x36/0x50 [ 39.337396] vfs_kern_mount.part.16+0x54/0x160 [ 39.337774] do_mount+0x20e/0xdf0 [ 39.338059] ? memdup_user+0x3e/0x70 [ 39.338365] __ia32_compat_sys_mount+0xa3/0x140 [ 39.338749] do_fast_syscall_32+0x9d/0x2f0 [ 39.339098] entry_SYSENTER_compat+0x84/0x96 [ 39.340891] XFS (loop0): Internal error xlog_valid_rec_header(2) at line 5283 of file fs/xfs/xfs_log_recover.c. Caller xlog_do_recovery_pass+0x2bd/0x5d0 [ 39.342084] CPU: 0 PID: 373 Comm: mount Not tainted 4.19.0-xfstests #1 [ 39.342636] Hardware name: QEMU
Re: [PATCH 2/2] iio: pressure: Add support for Honeywell HSC SPI sensors
On Fri, 26 Oct 2018 18:14:37 +
Carlos Iglesias wrote:
> Add device driver for the HSC pressure sensors with SPI interface.
> In addition to the main measurement -pressure- these sensors also
> provide temperature measurement.
>
> Signed-off-by: Carlos Iglesias
Hi Carlos,
A few minor things inline. Note that the spi buffer isn't currently
dma safe which may result in some really hard to find bugs (I've chased
these in the past and they can be really rare and tricky to track down!)
Jonathan
> ---
> MAINTAINERS| 6 +
> drivers/iio/pressure/Kconfig | 10 +
> drivers/iio/pressure/Makefile | 2 +
> drivers/iio/pressure/hsc_spi.c | 543 +
> 4 files changed, 561 insertions(+)
> create mode 100644 drivers/iio/pressure/hsc_spi.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 556f902b3766..a4af4cbd4b0f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6696,6 +6696,12 @@ W:
> http://artax.karlin.mff.cuni.cz/~mikulas/vyplody/hpfs/index-e.cgi
> S: Maintained
> F: fs/hpfs/
>
> +HSC SERIES PRESSURE SENSORS
> +M; Carlos Iglesias
> +S: Maintained
> +F: Documentation/devicetree/bindings/iio/pressure/hsc_spi.txt
> +F: drivers/iio/pressure/hsc_spi.c
> +
> HSI SUBSYSTEM
> M: Sebastian Reichel
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git
> diff --git a/drivers/iio/pressure/Kconfig b/drivers/iio/pressure/Kconfig
> index eaa7cfcb4c2a..593663d4ffa8 100644
> --- a/drivers/iio/pressure/Kconfig
> +++ b/drivers/iio/pressure/Kconfig
> @@ -227,4 +227,14 @@ config ZPA2326_SPI
> tristate
> select REGMAP_SPI
>
> +config HSC_SPI
> + tristate "Honeywell HSC pressure sensors (SPI)"
> + depends on SPI_MASTER
> + help
> + Say yes here to build support for the Honeywell HSC range of
> + pressure sensors (SPI interface only).
> +
> + To compile this driver as a module, choose M here: the module will
> + be called hsc_spi.
> +
> endmenu
> diff --git a/drivers/iio/pressure/Makefile b/drivers/iio/pressure/Makefile
> index c2058d7b2f93..b1db2116e9f6 100644
> --- a/drivers/iio/pressure/Makefile
> +++ b/drivers/iio/pressure/Makefile
> @@ -31,3 +31,5 @@ obj-$(CONFIG_ZPA2326_SPI) += zpa2326_spi.o
>
> obj-$(CONFIG_IIO_ST_PRESS_I2C) += st_pressure_i2c.o
> obj-$(CONFIG_IIO_ST_PRESS_SPI) += st_pressure_spi.o
> +
> +obj-$(CONFIG_HSC_SPI) += hsc_spi.o
> diff --git a/drivers/iio/pressure/hsc_spi.c b/drivers/iio/pressure/hsc_spi.c
> new file mode 100644
> index ..efe45a09da8f
> --- /dev/null
> +++ b/drivers/iio/pressure/hsc_spi.c
> @@ -0,0 +1,543 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * hsc_spi.c - Driver for Honeywell HSC pressure sensors with
> + * SPI interface
> + *
> + * Copyright (c) 2018 Carlos Iglesias
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define HSC_MAX_SPI_FREQ_HZ 40
> +
> +#define HSC_TEMP_BITS11
> +#define HSC_PRESS_BITS 14
> +#define HSC_TEMP_MASK(0x7FF)
> +#define HSC_TEMP_SHIFT (5)
> +
> +#define HSC_STATUS_S0BIT(14)
> +#define HSC_STATUS_S1BIT(15)
> +#define HSC_STATUS_MSK ((HSC_STATUS_S0) | (HSC_STATUS_S1))
> +#define HSC_STATUS_CMD HSC_STATUS_S0
> +#define HSC_STATUS_STALE HSC_STATUS_S1
> +#define HSC_STATUS_DIAG ((HSC_STATUS_S0) | (HSC_STATUS_S1))
> +
> +static inline int hsc_status_error(struct device dev, int val)
> +{
> + int st_check = val & HSC_STATUS_MSK;
> +
> + if (st_check) {
> + switch (st_check) {
> + case HSC_STATUS_CMD:
> + dev_warn(, "%s:Device in COMMAND MODE\n",
> + __func__);
> + return -EIO;
> + case HSC_STATUS_STALE:
> + dev_warn(, "%s:Stale data - sampling too fast?\n",
> + __func__);
> + return -EAGAIN;
> + case HSC_STATUS_DIAG:
> + dev_warn(, "%s:Calibration signature changed\n",
> + __func__);
> + return -EIO;
> + default:
> + dev_err(, "%s:Invalid status code (%d)\n",
> + __func__, st_check);
> + return -EIO;
> + }
> + }
> +
> + return 0;
> +}
> +
> +enum hsc_variant {
> + /* Note: Only the absolute range sensors are supported */
> + HSC001BAA, HSC001BAB, HSC001BAC, HSC001BAF,
> + HSC1_6BAA, HSC1_6BAB, HSC1_6BAC, HSC1_6BAF,
> + HSC2_5BAA, HSC2_5BAB, HSC2_5BAC, HSC2_5BAF,
> + HSC004BAA, HSC004BAB, HSC004BAC, HSC004BAF,
> + HSC006BAA, HSC006BAB, HSC006BAC, HSC006BAF,
> + HSC010BAA, HSC010BAB, HSC010BAC, HSC010BAF,
> +
> + HSC100KAA, HSC100KAB, HSC100KAC, HSC100KAF,
> +
Re: [PATCH 0/2] tracing: Fix synthetic event parser
On Sun, 28 Oct 2018 12:10:17 -0600 Shuah Khan wrote: > Here it is > > Acked-by: Shuah Khan > Thanks a lot Shuah! -- Steve
Logitech high-resolution scrolling..
So I use a Logitech MX Anywhere 2S mouse, and really like it. I have the scroll-wheel unlocked, because I like flicking once to scroll a lot. However, the new high-res scroll code means that the scroll wheel action is now much too sensitive. It's not even stable - it will scroll back-and-forth a bit occasionally, and in fact it sometimes seems to scroll not because I touch the scroll-wheel, but because the movement of the mouse itself causes the scroll wheel to move slightly and wiggle the scroll action. So the recent change to enable the high-res scrolling really seems a bit *too* extreme. Is there some middle ground that turns the mouse from "look at it sideways and it starts scrolling" to something slightly more reasonable? Linus
Re: [GIT PULL] XArray for 4.20
On Sun, Oct 28, 2018 at 11:50:19AM -0700, Linus Torvalds wrote: > On Tue, Oct 23, 2018 at 1:08 PM Matthew Wilcox wrote: > < > > Please consider pulling the XArray patch set. > > Pulled. Thanks! > I took the more recent version of yours, because by the time I > actually had time to review this thing for pulling, even the recent > version had been in linux-next for a week. > > Of course, I don't think linux-next has been updated, so it's all > moot, but the point is that I didn't get the feeling that it was all > some very recent code. > > I do like how the conversions look, with the code in some cases > notably simpler. And it looks like at least one of the conflicts > (fs/dax.c) was due to a bug-fix to the old code where your simpler > xarray replacement didn't have the problem. Yes, that's right. It turned out to be a problem for any multiorder radix tree user, and that was a consequence of how the radix tree API worked for multiorder entries. The XArray API just works better for multiorder entries. > NOTE! I did get some conflicts with other stuff, and while the > conflict resolution all looked pretty straightforward, this does want > looking at. > > Particularly the mm/workingset.c code. I've been rebasing the xarray-conv branch on your tree pretty regularly this week, so I have a fairly good idea how I think it should look. I'll check to see if you & I have the same thoughts when you push it out. > It's still undergoing my build tests to verify my merge, but that > should be completed soon. I'll do a basic boot test too due to the > core nature of these changes, but assuming it all passes I'll push > this out within the next 30 minutes and would appreciate people giving > it a second look for verification. Thank you.
RTL8812au driver source code A little help please?
make[1]: Entering directory '/usr/src/linux-4.19'
CC [M] /tmp/rtl8812AU_8821AU_linux/os_dep/linux/os_intfs.o
/tmp/rtl8812AU_8821AU_linux/os_dep/linux/os_intfs.c:816:22: error:
initialization of ‘u16 (*)(struct net_device *, struct sk_buff *,
struct net_device *, u16 (*)(struct net_device *, struct sk_buff *,
struct net_device *))’ {aka ‘short unsigned int (*)(struct net_device
*, struct sk_buff *, struct net_device *, short unsigned int
(*)(struct net_device *, struct sk_buff *, struct net_device *))’}
from incompatible pointer type ‘u16 (*)(struct net_device *, struct
sk_buff *, void *, u16 (*)(struct net_device *, struct sk_buff *,
struct net_device *))’ {aka ‘short unsigned int (*)(struct net_device
*, struct sk_buff *, void *, short unsigned int (*)(struct net_device
*, struct sk_buff *, struct net_device *))’}
[-Werror=incompatible-pointer-types]
.ndo_select_queue = rtw_select_queue,
^~~~
/tmp/rtl8812AU_8821AU_linux/os_dep/linux/os_intfs.c:816:22: note:
(near initialization for ‘rtw_netdev_ops.ndo_select_queue’)
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:306:
/tmp/rtl8812AU_8821AU_linux/os_dep/linux/os_intfs.o] Error 1
make[1]: *** [Makefile:1517: _module_/tmp/rtl8812AU_8821AU_linux] Error 2
make[1]: Leaving directory '/usr/src/linux-4.19'
make: *** [Makefile:1584: modules] Error 2
I Kinda need some help figuring out how to make this compile on kernel
source 4.19.0?
Any help would be apprectiated,
Re: [PATCH v6 3/3] staging: iio: ad2s1210: Add device tree support.
On Sun, Oct 28, 2018 at 02:51:08PM +, Jonathan Cameron wrote:
> On Sun, 28 Oct 2018 13:23:23 +0530
> Nishad Kamdar wrote:
>
> > Replace platform data with device tree support.
> >
> > Signed-off-by: Nishad Kamdar
> The whole gpio in or out thing makes less and less sense to
> me and seems to contradict the datasheet.
>
> If I'm not missing something I would just get rid of the option.
> If I am missing something (not hard in the datasheet which, whilst
> fairly clear, is a rather long ;)
>
> Jonathan
>
Ok, I'll drop it.
> > ---
> > drivers/staging/iio/resolver/Kconfig| 1 +
> > drivers/staging/iio/resolver/ad2s1210.c | 17 -
> > drivers/staging/iio/resolver/ad2s1210.h | 17 -
> > 3 files changed, 9 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/staging/iio/resolver/Kconfig
> > b/drivers/staging/iio/resolver/Kconfig
> > index 6a469ee6101f..cc1202ff813d 100644
> > --- a/drivers/staging/iio/resolver/Kconfig
> > +++ b/drivers/staging/iio/resolver/Kconfig
> > @@ -15,6 +15,7 @@ config AD2S90
> >
> > config AD2S1210
> > tristate "Analog Devices ad2s1210 driver"
> > + depends on OF
> > depends on SPI
> > depends on GPIOLIB || COMPILE_TEST
> > help
> > diff --git a/drivers/staging/iio/resolver/ad2s1210.c
> > b/drivers/staging/iio/resolver/ad2s1210.c
> > index 0234869e9d74..5ecdb5785132 100644
> > --- a/drivers/staging/iio/resolver/ad2s1210.c
> > +++ b/drivers/staging/iio/resolver/ad2s1210.c
> > @@ -17,6 +17,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -76,7 +77,6 @@ struct ad2s1210_gpio {
> > };
> >
> > struct ad2s1210_state {
> > - const struct ad2s1210_platform_data *pdata;
> > struct mutex lock;
> > struct spi_device *sdev;
> > struct gpio_desc *sample;
> > @@ -84,6 +84,7 @@ struct ad2s1210_state {
> > struct gpio_desc *a1;
> > struct gpio_desc *res0;
> > struct gpio_desc *res1;
> > + bool gpioin;
> > unsigned int fclkin;
> > unsigned int fexcit;
> > bool hysteresis;
> > @@ -314,7 +315,7 @@ static ssize_t ad2s1210_store_control(struct device
> > *dev,
> > }
> > st->resolution
> > = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
> > - if (st->pdata->gpioin) {
> > + if (st->gpioin) {
> > data = ad2s1210_read_resolution_pin(st);
> > if (data != st->resolution)
> > dev_warn(dev, "ad2s1210: resolution settings not
> > match\n");
> > @@ -376,7 +377,7 @@ static ssize_t ad2s1210_store_resolution(struct device
> > *dev,
> > }
> > st->resolution
> > = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
> > - if (st->pdata->gpioin) {
> > + if (st->gpioin) {
> > data = ad2s1210_read_resolution_pin(st);
> > if (data != st->resolution)
> > dev_warn(dev, "ad2s1210: resolution settings not
> > match\n");
> > @@ -603,7 +604,7 @@ static int ad2s1210_initial(struct ad2s1210_state *st)
> > int ret;
> >
> > mutex_lock(>lock);
> > - if (st->pdata->gpioin)
> > + if (st->gpioin)
> > st->resolution = ad2s1210_read_resolution_pin(st);
> > else
> > ad2s1210_set_resolution_pin(st);
> > @@ -644,7 +645,7 @@ static int ad2s1210_setup_gpios(struct ad2s1210_state
> > *st)
> > int ret, i;
> > struct spi_device *spi = st->sdev;
> > struct ad2s1210_gpio *pin;
> > - unsigned long flags = st->pdata->gpioin ? GPIOD_IN : GPIOD_OUT_LOW;
> > + unsigned long flags = st->gpioin ? GPIOD_IN : GPIOD_OUT_LOW;
> >
> > struct ad2s1210_gpio gpios[] = {
> > { .ptr = >sample, .name = "sample", .flags = GPIOD_IN },
> > @@ -673,16 +674,14 @@ static int ad2s1210_probe(struct spi_device *spi)
> > {
> > struct iio_dev *indio_dev;
> > struct ad2s1210_state *st;
> > + struct device_node *np = spi->dev.of_node;
> > int ret;
> >
> > - if (!spi->dev.platform_data)
> > - return -EINVAL;
> > -
> > indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
> > if (!indio_dev)
> > return -ENOMEM;
> > st = iio_priv(indio_dev);
> > - st->pdata = spi->dev.platform_data;
> > + st->gpioin = of_property_read_bool(np, "gpioin");
>
> Hmm. This bothered me in the earlier patch. How are we meant to configure
> these pins... (and this time I actually loaded the datasheet)
>
> A0 and A1 always seem to be control signals written to the device so
> I don't really understand why we would ever want them to be 'inputs'
> on our host.
>
> RES0 and RES1 are also control signals. Clearly marked as logic inputs.
>
> The only thing I can think here is there is an evaluation board out there
> were we are not in control of these, some other controller is.
> That is a pretty weird board if so, hence I would only support the version
> where we use GPIO outputs from the host.
>
> This will further simplify patch 1 and get
Loan Offer
We offer all types of loans at 2% interest rate contact us at gylesloan...@gmail.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [PATCH RFC 16/18] staging: vchiq_arm: rework probe and init functions
> Nicolas Saenz Julienne hat am 26. Oktober 2018 um > 15:48 geschrieben: > > > Some operations performed in the probe function should have been > implemented in the init function. Namely class and dev region creations. > Please explain the why in the commit log
Re: [PATCH 0/9 v3] locks: avoid thundering-herd wake-ups
On Fri, Oct 26 2018, Jeff Layton wrote: > On Wed, 2018-10-24 at 09:43 +1100, NeilBrown wrote: >> This took longer that I had wanted, due to various reasons - sorry. >> And I'm now posting it in a merge window, which is not ideal. I don't >> expect it to be included in this merge window and I won't be at all >> impatient for review, but I didn't want to delay it further. >> >> Testing found some problems, particularly the need to use >> locks_copy_lock in NFS. And there was a small thinko in there that >> effectively removed all the speed gains :-( >> >> But this version: >> - shows excellent scalability with lots of threads on lots of CPUs >>contending on a single file >> - avoids the problems that Bruce found >> - seems to work. >> >> Thanks, >> NeilBrown >> >> >> --- >> >> NeilBrown (9): >> fs/locks: rename some lists and pointers. >> fs/locks: split out __locks_wake_up_blocks(). >> NFS: use locks_copy_lock() to copy locks. >> fs/locks: allow a lock request to block other requests. >> fs/locks: always delete_block after waiting. >> fs/locks: change all *_conflict() functions to return bool. >> fs/locks: create a tree of dependent requests. >> locks: merge posix_unblock_lock() and locks_delete_block() >> VFS: locks: remove unnecessary white space. >> >> >> fs/cifs/file.c |4 - >> fs/lockd/svclock.c |2 >> fs/locks.c | 231 >> ++- >> fs/nfs/nfs4proc.c |6 + >> fs/nfsd/nfs4state.c |6 + >> include/linux/fs.h | 11 +- >> include/trace/events/filelock.h | 16 +-- >> 7 files changed, 153 insertions(+), 123 deletions(-) >> >> -- >> Signature >> > > > I built a kernel with these patches and ran the cthon04 lock tests and > got this on lock test 1 after a long hang (the test passed though): Thanks! I think locks_remove_posix() needs a call to locks_init_lock(); just like locks_mandatory_area() has. I cannot immediately see anywhere else it is needed but I should probably look a bit harder. Thanks, NeilBrown > > [ 1694.787367] BUG: unable to handle kernel NULL pointer dereference at > 002c > [ 1694.789546] PGD 118ff0067 P4D 118ff0067 PUD 135915067 PMD 0 > [ 1694.790772] Oops: [#1] SMP NOPTI > [ 1694.791749] CPU: 7 PID: 1514 Comm: tlocklfs Not tainted 4.19.0+ #56 > [ 1694.792876] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > ?-20180531_142017-buildhw-08.phx2.fedoraproject.org-1.fc28 04/01/2014 > [ 1694.795179] RIP: 0010:__locks_delete_block+0x14/0x90 > [ 1694.796203] Code: 01 a1 e9 9f 4f d8 ff 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 > 00 00 00 0f 1f 44 00 00 8b 05 29 9d 58 01 55 53 48 89 fb 85 c0 75 5a <48> 8b > 43 20 48 85 c0 74 20 48 8b 53 18 48 89 10 48 85 d2 74 04 48 > [ 1694.799277] RSP: 0018:9d21c1f63cb8 EFLAGS: 00010202 > [ 1694.800374] RAX: 0001 RBX: 000c RCX: > aaad > [ 1694.801682] RDX: 0001 RSI: 9f7b0c38 RDI: > 0246 > [ 1694.802996] RBP: 000c R08: R09: > 0001 > [ 1694.804317] R10: 0001 R11: a0bdc188 R12: > 9d21c1f63dd8 > [ 1694.805633] R13: 9d21c1f63e00 R14: 9f3241a8 R15: > 8d0b5aef72e0 > [ 1694.806941] FS: 7efc8699c740() GS:8d0b7ba0() > knlGS: > [ 1694.808380] CS: 0010 DS: ES: CR0: 80050033 > [ 1694.809550] CR2: 002c CR3: 00011e0d8000 CR4: > 06e0 > [ 1694.810888] Call Trace: > [ 1694.811692] __locks_wake_up_blocks+0x2d/0x80 > [ 1694.812713] locks_delete_block+0x1d/0x40 > [ 1694.813691] locks_lock_inode_wait+0x9c/0x1c0 > [ 1694.814731] nfs4_proc_lock+0x120/0x440 [nfsv4] > [ 1694.815786] ? nfs_put_lock_context+0x25/0x80 [nfs] > [ 1694.816866] ? do_unlk+0x98/0xe0 [nfs] > [ 1694.817818] locks_remove_posix+0xba/0x1d0 > [ 1694.818811] ? _cond_resched+0x15/0x30 > [ 1694.819768] ? wait_on_commit+0x38/0xb0 [nfs] > [ 1694.820787] ? process_echoes+0x60/0x60 > [ 1694.821752] ? __nfs_commit_inode+0xc2/0x1c0 [nfs] > [ 1694.822819] filp_close+0x56/0x70 > [ 1694.823712] __x64_sys_close+0x1e/0x50 > [ 1694.824661] do_syscall_64+0x60/0x1f0 > [ 1694.825599] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 1694.826731] RIP: 0033:0x7efc8616c0a4 > [ 1694.827673] Code: eb 89 e8 af f6 01 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f > 44 00 00 8b 05 aa e7 2c 00 48 63 ff 85 c0 75 13 b8 03 00 00 00 0f 05 <48> 3d > 00 f0 ff ff 77 44 f3 c3 66 90 48 83 ec 18 48 89 7c 24 08 e8 > [ 1694.830929] RSP: 002b:7ffc70beb7b8 EFLAGS: 0246 ORIG_RAX: > 0003 > [ 1694.832371] RAX: ffda RBX: RCX: > 7efc8616c0a4 > [ 1694.833784] RDX: RSI: 7efc864378a0 RDI: > 0009 > [ 1694.835183] RBP: 7ffc70beb7d0 R08: 7efc864378a0 R09: > 7efc8699c740 > [
Re: [GIT PULL] XArray for 4.20
On Tue, Oct 23, 2018 at 1:08 PM Matthew Wilcox wrote: < > Please consider pulling the XArray patch set. Pulled. I took the more recent version of yours, because by the time I actually had time to review this thing for pulling, even the recent version had been in linux-next for a week. Of course, I don't think linux-next has been updated, so it's all moot, but the point is that I didn't get the feeling that it was all some very recent code. I do like how the conversions look, with the code in some cases notably simpler. And it looks like at least one of the conflicts (fs/dax.c) was due to a bug-fix to the old code where your simpler xarray replacement didn't have the problem. NOTE! I did get some conflicts with other stuff, and while the conflict resolution all looked pretty straightforward, this does want looking at. Particularly the mm/workingset.c code. It's still undergoing my build tests to verify my merge, but that should be completed soon. I'll do a basic boot test too due to the core nature of these changes, but assuming it all passes I'll push this out within the next 30 minutes and would appreciate people giving it a second look for verification. Thanks, Linus
Re: [PATCH RFC 09/18] staging: vchiq_core: do not initialize semaphores twice
Hi Nicolas, > Nicolas Saenz Julienne hat am 26. Oktober 2018 um > 15:48 geschrieben: > > > vchiq_init_state() initialises a series of semaphores to then call > remote_event_create() on the same semaphores, which initializes them > again. i would prefer to have all init stuff at one place in vchiq_init_state() and drop this ugliness from remote_event_create() instead. Is this possible?
Re: [PATCH RFC 15/18] stagning: vchiq_core: fix logic redundancy in parse_open
> Nicolas Saenz Julienne hat am 26. Oktober 2018 um > 15:48 geschrieben: > > > We update sync to reflect that the firmware version is compatible with > that option. We don't need to check both of them again further down the > code. please fix the typo in the subject s/stagning/staging/ for this patch and patch #4
Re: [GIT PULL] C-SKY(csky) Port for Linux 4.20
Arnd, I was kind of hoping/expecting to get an explicit ack for this from you, since it's a new architecture. Good to merge? Linus On Fri, Oct 26, 2018 at 9:08 PM Guo Ren wrote: > > This tag contains the Linux port for C-SKY(csky) based on linux-4.19 > Release, which has been through 10 rounds of review on mailing list. > > We almost got the Acked-by/Reviewed-by of all patches except "Process > management and Signal", but all've been tested.
Re: [PATCH RFC 18/18] staging: vchiq: add more tasks to the TODO list
> Nicolas Saenz Julienne hat am 26. Oktober 2018 um > 15:48 geschrieben: > > > The more the better. Please try to find a better commit log ;-) > > Signed-off-by: Nicolas Saenz Julienne > --- > .../staging/vc04_services/interface/vchi/TODO | 46 ++- > 1 file changed, 44 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/vc04_services/interface/vchi/TODO > b/drivers/staging/vc04_services/interface/vchi/TODO > index 0b3ec75ff627..bf2135826431 100644 > --- a/drivers/staging/vc04_services/interface/vchi/TODO > +++ b/drivers/staging/vc04_services/interface/vchi/TODO > @@ -27,8 +27,8 @@ unused. > 3) Make driver more portable > > Building this driver with arm/multi_v7_defconfig or arm64/defconfig > -leads to data corruption during the following command: > - > +leads to data corruption during the following command: > + I assume this wasn't intended. Btw after applying Phil's patch series. This point can be dropped. Beside that i'm fine with the additions.
[PATCH] ubifs: Handle re-linking of inodes correctly while recovery
UBIFS's recovery code strictly assumes that a deleted inode will never
come back, therefore it removes all data which belongs to that inode
as soon it faces an inode with link count 0 in the replay list.
Before O_TMPFILE this assumption was perfectly fine. With O_TMPFILE
it can lead to data loss upon a power-cut.
Consider a journal with entries like:
0: inode X (nlink = 0) /* O_TMPFILE was created */
1: data for inode X /* Someone writes to the temp file */
2: inode X (nlink = 0) /* inode was changed, xattr, chmod, … */
3: inode X (nlink = 1) /* inode was re-linked via linkat() */
Upon replay of entry #2 UBIFS will drop all data that belongs to inode X,
this will lead to an empty file after mounting.
As solution for this problem, scan the replay list for a re-link entry
before dropping data.
Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE")
Cc: sta...@vger.kernel.org
Reported-by: Russell Senior
Reported-by: Rafał Miłecki
Signed-off-by: Richard Weinberger
---
Russel, Rafał,
please give this patch another testing.
I'll also run it on different test systems before merging.
Thanks,
//richard
---
fs/ubifs/replay.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
index 4844538eb926..65a780685b82 100644
--- a/fs/ubifs/replay.c
+++ b/fs/ubifs/replay.c
@@ -209,6 +209,34 @@ static int trun_remove_range(struct ubifs_info *c, struct
replay_entry *r)
return ubifs_tnc_remove_range(c, _key, _key);
}
+/**
+ * inode_relinked - check whether inode in question will be re-linked.
+ * @c: UBIFS file-system description object
+ * @rino: replay entry to test
+ *
+ * O_TMPFILE files can be re-linked, this means link count goes from 0 to 1.
+ * This case needs special care, otherwise all references to the inode will
+ * be removed upon the first replay entry of an inode with link count 0
+ * is found.
+ */
+static bool inode_relinked(struct ubifs_info *c, struct replay_entry *rino)
+{
+ struct replay_entry *r = rino;
+
+ ubifs_assert(c, rino->deletion);
+ ubifs_assert(c, key_type(c, >key) == UBIFS_INO_KEY);
+
+ list_for_each_entry_from(r, >replay_list, list) {
+ if (key_inum(c, >key) == key_inum(c, >key) &&
+ r->deletion == 0) {
+ ubifs_assert(c, r->sqnum > rino->sqnum);
+ return true;
+ }
+ }
+
+ return false;
+}
+
/**
* apply_replay_entry - apply a replay entry to the TNC.
* @c: UBIFS file-system description object
@@ -236,6 +264,11 @@ static int apply_replay_entry(struct ubifs_info *c, struct
replay_entry *r)
{
ino_t inum = key_inum(c, >key);
+ if (inode_relinked(c, r)) {
+ err = 0;
+ break;
+ }
+
err = ubifs_tnc_remove_ino(c, inum);
break;
}
--
2.19.1
Re: [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings
On Mon, 22 Oct 2018, Zi Yan wrote: > Hi David, > Hi! > On 22 Oct 2018, at 17:04, David Rientjes wrote: > > > On Tue, 16 Oct 2018, Mel Gorman wrote: > > > > > I consider this to be an unfortunate outcome. On the one hand, we have a > > > problem that three people can trivially reproduce with known test cases > > > and a patch shown to resolve the problem. Two of those three people work > > > on distributions that are exposed to a large number of users. On the > > > other, we have a problem that requires the system to be in a specific > > > state and an unknown workload that suffers badly from the remote access > > > penalties with a patch that has review concerns and has not been proven > > > to resolve the trivial cases. > > > > The specific state is that remote memory is fragmented as well, this is > > not atypical. Removing __GFP_THISNODE to avoid thrashing a zone will only > > be beneficial when you can allocate remotely instead. When you cannot > > allocate remotely instead, you've made the problem much worse for > > something that should be __GFP_NORETRY in the first place (and was for > > years) and should never thrash. > > > > I'm not interested in patches that require remote nodes to have an > > abundance of free or unfragmented memory to avoid regressing. > > I just wonder what is the page allocation priority list in your environment, > assuming all memory nodes are so fragmented that no huge pages can be > obtained without compaction or reclaim. > > Here is my version of that list, please let me know if it makes sense to you: > > 1. local huge pages: with compaction and/or page reclaim, you are willing > to pay the penalty of getting huge pages; > > 2. local base pages: since, in your system, remote data accesses have much > higher penalty than the extra TLB misses incurred by the base page size; > > 3. remote huge pages: at least it is better than remote base pages; > > 4. remote base pages: it performs worst in terms of locality and TLBs. > I have a ton of different platforms available. Consider a very basic access latency evaluation on Broadwell on a running production system: remote hugepage vs remote PAGE_SIZE pages had about 5% better access latency. Remote PAGE_SIZE pages vs local pages is a 12% degradation. On Naples, remote hugepage vs remote PAGE_SIZE had 2% better access latency intrasocket, no better access latency intersocket. Remote PAGE_SIZE pages vs local is a 16% degradation intrasocket and 38% degradation intersocket. My list removes (3) from your list, but is otherwise unchanged. I remove (3) because 2-5% better access latency is nice, but we'd much rather fault local base pages and then let khugepaged collapse it into a local hugepage when fragmentation is improved or we have freed memory. That is where we can get a much better result, 41% better access latency on Broadwell and 52% better access latncy on Naples. I wouldn't trade that for 2-5% immediate remote hugepages. It just so happens that prior to this patch, the implementation of the page allocator matches this preference. > In addition, to prioritize local base pages over remote pages, > the original huge page allocation has to fail, then kernel can > fall back to base page allocations. And you will never get remote > huge pages any more if the local base page allocation fails, > because there is no way back to huge page allocation after the fallback. > That is exactly what we want, we want khugepaged to collapse memory into local hugepages for the big improvement rather than persistently access a hugepage remotely; the win of the remote hugepage just isn't substantial enough, and the win of the local hugepage is just too great. > > I'd like to know, specifically: > > > > - what measurable affect my patch has that is better solved with removing > >__GFP_THISNODE on systems where remote memory is also fragmented? > > > > - what platforms benefit from remote access to hugepages vs accessing > >local small pages (I've asked this maybe 4 or 5 times now)? > > > > - how is reclaiming (and possibly thrashing) memory helpful if compaction > >fails to free an entire pageblock due to slab fragmentation due to low > >on memory conditions and the page allocator preference to return node- > >local memory? > > > > - how is reclaiming (and possibly thrashing) memory helpful if compaction > >cannot access the memory reclaimed because the freeing scanner has > >already passed by it, or the migration scanner has passed by it, since > >this reclaim is not targeted to pages it can find? > > > > - what metrics can be introduced to the page allocator so that we can > >determine that reclaiming (and possibly thrashing) memory will result > >in a hugepage being allocated? > > The slab fragmentation and whether reclaim/compaction can help form > huge pages seem to orthogonal to this patch, which tries to decide > the priority between locality and
Re: [PATCH 1/2] i2c: Remove unnecessary call to irq_find_mapping
On Fri, Oct 19, 2018 at 09:59:57AM +0100, Charles Keepax wrote: > irq_create_mapping calls irq_find_mapping internally and will use the > found mapping if one exists, so there is no need to manually call this > from i2c_smbus_host_notify_to_irq. > > Signed-off-by: Charles Keepax Adding Benjamin to recipients. He wrote that code. > --- > drivers/i2c/i2c-core-base.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c > index dc78aa7369def..656f0a6fe3adf 100644 > --- a/drivers/i2c/i2c-core-base.c > +++ b/drivers/i2c/i2c-core-base.c > @@ -306,10 +306,7 @@ static int i2c_smbus_host_notify_to_irq(const struct > i2c_client *client) > if (client->flags & I2C_CLIENT_TEN) > return -EINVAL; > > - irq = irq_find_mapping(adap->host_notify_domain, client->addr); > - if (!irq) > - irq = irq_create_mapping(adap->host_notify_domain, > - client->addr); > + irq = irq_create_mapping(adap->host_notify_domain, client->addr); > > return irq > 0 ? irq : -ENXIO; > } > -- > 2.11.0 > signature.asc Description: PGP signature
linux-next: manual merge of the arm-soc tree with Linus' tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in:
drivers/soc/qcom/Kconfig
between commit:
a978a5b8d83f ("net/kconfig: Make QCOM_QMI_HELPERS available when
COMPILE_TEST")
from Linus' tree and commit:
ccfb464cd106 ("soc: qcom: Allow COMPILE_TEST of qcom SoC Kconfigs")
from the arm-soc tree.
I fixed it up (I just used the version in Linus' tree) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpD8hNCRckk_.pgp
Description: OpenPGP digital signature
Re: [RFR] Store tearing
Hopefully, with Paul's proper email address this time, Andrea On Mon, Oct 29, 2018 at 12:06:27AM +0100, Andrea Parri wrote: > Hi, > > memory-barriers.txt says: > > [on "store tearing"] > > "In fact, a recent bug (since fixed) caused GCC to incorrectly use >this optimization in a volatile store.". > > I was wondering if you could help me retrieve some reference/discussions > about this? > > Thanks, > Andrea
Re: w1: coding style and checkpatch fixes
Hi Linus, Thanks! Its hopefully fixed now. For those who are interested. Rspamd, by default, includes the sender address into the list of signed headers: https://www.rspamd.com/doc/modules/dkim_signing.html#default-sign_headers-after-173 > End result: the DKIM signature is guaranteed to fail after the email > has gone through a mailing list. There is RFC6377 which discusses this problem. On possible solution is a mailing list service which understands DKIM and can check/sign the messages. See: https://tools.ietf.org/html/rfc6377 > You do have a few other oddities in there (the duplication of the > common fields), but they shouldn't matter. This is actually according to RFC. Listing signed header-fields multiple times prohibits them from beeing modified and resigned my other MTAs. Thanks again, Steffen On Sun, Oct 28, 2018 at 03:53:07PM -0700, Linus Torvalds wrote: > [ This is not about your patch series per se, only about your email settings ] > > On Sun, Oct 28, 2018 at 3:20 PM Steffen Vogel wrote: > > > > This is my first series of patches for the Linux kernel. > > I started by familiarizing myself with coding style and > > satisfying my inner OCD by cleaning the 1-wire subsystem. > > Sadly, your DKIM setup is wrong, causing all the emails to be marked > as spam when they go through a mailing list. > > Your DKIM header looks like this: > > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steffenvogel.de; > s=2017; t=1540764601; > h=from:from:sender:reply-to:subject:subject:date:date: > message-id:message-id:to:to:cc:cc:mime-version:mime-version: > content-type:content-transfer-encoding:content-transfer-encoding: > in-reply-to:in-reply-to:references:references; > > and the problem with that is the "sender" field in there. > > A good mailing list will not change the contents of your email, or > most of the other headers, but it *will* set the sender field to the > mailing list. > > > In other words, putting the sender field as part of the DKIM-checked > headers is just wrong. It's a somewhat common mistake, but it's still > wrong. I wonder where people get their setups from, because I think > there is some DKIM guide on the internet that is actively spreading > this bad behavior. > > > Linus
Re: [RFC] rcu: doc: update example about stale data
On Sat, Oct 27, 2018 at 09:44:31PM -0700, Joel Fernandes wrote: > On Sat, Oct 27, 2018 at 7:16 PM, Joel Fernandes (Google) > wrote: > > The RCU example for 'rejecting stale data' on system-call auditting > > stops iterating through the rules if a deleted one is found. It makes > > more sense to continue looking at other rules once a deleted one is > > rejected. Although the original example is fine, this makes it more > > meaningful. > > Sorry, I messed up the patch title, it is supposed to be 'doc: rcu: > ...'. I can resend it if you want. Hmmm... There doesn't seem to be any consistent standard for documentation patches. I see "Documentation: networking:", "docs:", "doc:" (which is what I normally use), "doc:doc-guide:", "Documentation/process:", "doc/devicetree:", "media: doc:", and who knows what all else. Including "Documentation" seems excessive. I guess I am OK with "doc: rcu:", but either just plain "doc:" or "doc/rcu:" would be fine with me as well. Thanx, Paul
Re: [GIT PULL] XArray for 4.20
On Sun, Oct 28, 2018 at 12:21:19PM -0700, Linus Torvalds wrote: > On Sun, Oct 28, 2018 at 12:13 PM Matthew Wilcox wrote: > > > > On Sun, Oct 28, 2018 at 11:50:19AM -0700, Linus Torvalds wrote: > > > > > NOTE! I did get some conflicts with other stuff, and while the > > > conflict resolution all looked pretty straightforward, this does want > > > looking at. > > > > > > Particularly the mm/workingset.c code. > > > > I've been rebasing the xarray-conv branch on your tree pretty regularly > > this week, so I have a fairly good idea how I think it should look. > > I'll check to see if you & I have the same thoughts when you push it out. > > It's pushed out now. I'm running the kernel now, but have done only > basic boot testing (in addition to my usual build tests), no real > stress-tests. Yep, no differences in how we resolved the conflicts.
Re: Which SPDX Identifier for files without explicit GPL version
On 10/28/18 3:13 PM, Greg Kroah-Hartman wrote: On Sun, Oct 28, 2018 at 02:22:40PM +0100, Michael Straube wrote: On 10/28/18 12:27 PM, Greg Kroah-Hartman wrote: On Sun, Oct 28, 2018 at 11:04:06AM +0100, Michael Straube wrote: Hi, which GPL version should be used in SPDX Identifiers for files that are GPL licensed but do not mention any version? It is not clear to me after reading license-rules.rst. For example: /** * Copyright(c) 2008 - 2010 Realtek Corporation. All rights reserved. * * 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. * * The full GNU General Public License is included in this distribution in the * file called LICENSE. Perhaps look up what version of the GPL that was originally contained in the tarball that this driver was bundled with? I think that should be on their website somewhere... If not, it's v1, not a good thing, but all we have to go on. Also, try emailing: * Contact Information: * wlanfae That address :) thanks, greg k-h Ah, there is a file 'license' in the root directory of this driver (rtl8192e) that I overlooked. It contains GPLv2. So v2 applies to all files with the above shortened boiler plate? Yes. So add a SPDX line to the file and delete the boiler plate text so we don't have this question again in the future. Then delete that opy of the GPL so we don't have files we don't need :) thanks, greg k-h Alright, thanks. :) There are two files left with no GPL version mentioned and no reference to a file with the license text. I'm unsure how to handle the two files, so better asking to get it right. Are they also covered by the license file in the root directory? /* IEEE 802.11 SoftMAC layer * Copyright (c) 2005 Andrea Merello * * Mostly extracted from the rtl8180-sa2400 driver for the * in-kernel generic ieee802.11 stack. * * Few lines might be stolen from other part of the rtllib * stack. Copyright who own it's copyright * * WPA code stolen from the ipw2200 driver. * Copyright who own it's copyright. * * released under the GPL */ /* IEEE 802.11 SoftMAC layer * Copyright (c) 2005 Andrea Merello * * Mostly extracted from the rtl8180-sa2400 driver for the * in-kernel generic ieee802.11 stack. * * Some pieces of code might be stolen from ipw2100 driver * copyright of who own it's copyright ;-) * * PS wx handler mostly stolen from hostap, copyright who * own it's copyright ;-) * * released under the GPL */ Perhaps you could say what GPL version to use in the SPDX line, Andrea? Thanks, Michael
Loan Offer
We offer all types of loans at 2% interest rate contact us at gylesloan...@gmail.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [PATCH RFC 11/18] staging: vchiq_arm: use completions instead of semaphores
> Nicolas Saenz Julienne hat am 26. Oktober 2018 um > 15:48 geschrieben: > > > It is preferred in the kernel to avoid using semaphores to wait for > events, as they are optimised for the opposite situation; where the > common case is that they are available and may block only occasionally. > FYI see this thread: https://lkml.org/lkml/2008/4/11/323. > > Also completions are semantically more explicit in this case. > Since patch #11 #12 and #13 doing the same, they could be fold.
Re: Your Loan Firm
Are you searching for a Genuine Loan? At an affordable interest rate? Get back to us with your Name and Phone Number Best Regards, Emrah Global Loan
Re: [PATCH 3/3] i2c: uniphier-f: fix race condition when IRQ is cleared
On Tue, Oct 16, 2018 at 12:01:49PM +0900, Masahiro Yamada wrote:
> The current IRQ handler clears all the IRQ status bits when it bails
> out. This is dangerous because it might clear away the status bits
> that have just been set while processing the current handler. If this
> happens, the IRQ event for the latest transfer is lost forever.
>
> The IRQ status bits must be cleared *before* the next transfer is
> kicked.
>
> Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver")
> Signed-off-by: Masahiro Yamada
Applied to for-next, thanks!
signature.asc
Description: PGP signature
Re: [PATCH 2/3] i2c: uniphier-f: fix occasional timeout error
On Tue, Oct 16, 2018 at 12:01:48PM +0900, Masahiro Yamada wrote:
> Currently, a timeout error could happen at a repeated START condition.
>
> For a (non-repeated) START condition, the controller starts sending
> data when the UNIPHIER_FI2C_CR_STA bit is set. However, for a repeated
> START condition, the hardware starts running when the slave address is
> written to the TX FIFO - the write to the UNIPHIER_FI2C_CR register is
> actually unneeded.
>
> Because the hardware is already running before the IRQ is enabled for
> a repeated START, the driver may miss the IRQ event. In most cases,
> this problem does not show up since modern CPUs are much faster than
> the I2C transfer. However, it is still possible that a context switch
> happens after the controller starts, but before the IRQ register is
> set up.
>
> To fix this,
>
> - Do not write UNIPHIER_FI2C_CR for repeated START conditions.
>
> - Enable IRQ *before* writing the slave address to the TX FIFO.
>
> - Disable IRQ for the current CPU while queuing up the TX FIFO;
>If the CPU is interrupted by some task, the interrupt handler
>might be invoked due to the empty TX FIFO before completing the
>setup.
>
> Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver")
> Signed-off-by: Masahiro Yamada
Applied to for-next, thanks!
signature.asc
Description: PGP signature
Re: [PATCH 1/3] i2c: uniphier-f: make driver robust against concurrency
On Tue, Oct 16, 2018 at 12:01:47PM +0900, Masahiro Yamada wrote:
> This is unlikely to happen, but it is possible for a CPU to enter
> the interrupt handler just after wait_for_completion_timeout() has
> expired. If this happens, the hardware is accessed from multiple
> contexts concurrently.
>
> Disable the IRQ after wait_for_completion_timeout(), and do nothing
> from the handler when the IRQ is disabled.
>
> Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver")
> Signed-off-by: Masahiro Yamada
Applied to for-next, thanks!
signature.asc
Description: PGP signature
Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove
On Fri, Oct 19, 2018 at 09:59:58AM +0100, Charles Keepax wrote: > The IRQ will be mapped in i2c_device_probe only if client->irq is zero and > i2c_device_remove does not clear this. When rebinding an I2C device, > whos IRQ provider has also been rebound this means that an IRQ mapping > will never be created, causing the I2C device to fail to acquire its > IRQ. Fix this issue by clearing client->irq in i2c_device_remove, > forcing i2c_device_probe to lookup the mapping again. > > Signed-off-by: Charles Keepax Adding Benjamin here again. Also, should there be a Fixes: tag? > --- > drivers/i2c/i2c-core-base.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c > index 656f0a6fe3adf..28460f6a60cc1 100644 > --- a/drivers/i2c/i2c-core-base.c > +++ b/drivers/i2c/i2c-core-base.c > @@ -430,6 +430,8 @@ static int i2c_device_remove(struct device *dev) > dev_pm_clear_wake_irq(>dev); > device_init_wakeup(>dev, false); > > + client->irq = 0; > + > return status; > } > > -- > 2.11.0 > signature.asc Description: PGP signature
Re: [PATCH 0/2] tracing: Fix synthetic event parser
On 10/28/2018 02:09 AM, Steven Rostedt wrote: > On Sun, 28 Oct 2018 04:01:35 -0400 > Steven Rostedt wrote: > >> I'll add them on top of my linux-next code, and include them in the >> pull request I'm hoping to do on Tuesday. > > Bah, I think this is on a different branch, and that will make it go as > a separate pull. Anyway, it probably will still be on Tuesday where I > push it to Linus. > > -- Steve > Here it is Acked-by: Shuah Khan thanks, -- Shuah
Re: [PATCH v3 1/4] x86/mm: declare check_la57_support() as inline
On Sun, 28 Oct 2018 13:09:42 +
Changbin Du wrote:
> The level4_kernel_pgt is only defined when X86_5LEVEL is enabled.
> So declare check_la57_support() as inline to make sure the code
> referring to level4_kernel_pgt is optimized out. This is a preparation
> for CONFIG_CC_OPTIMIZE_FOR_DEBUGGING.
>
> Signed-off-by: Changbin Du
Reviewed-by: Steven Rostedt (VMware)
-- Steve
> Cc: Masahiro Yamada
> ---
> arch/x86/kernel/head64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> index 5dc377dc9d7b..5ae682f2aa83 100644
> --- a/arch/x86/kernel/head64.c
> +++ b/arch/x86/kernel/head64.c
> @@ -98,7 +98,7 @@ static bool __head check_la57_support(unsigned long
> physaddr)
> return true;
> }
> #else
> -static bool __head check_la57_support(unsigned long physaddr)
> +static inline bool __head check_la57_support(unsigned long physaddr)
> {
> return false;
> }
Re: [PATCH v5 3/3] clk: meson: add sub MMC clock controller driver
On Thu, 2018-10-25 at 22:58 +0200, Martin Blumenstingl wrote:
> Hi Jerome,
>
> On Thu, Oct 25, 2018 at 2:54 PM Jerome Brunet wrote:
> [snip]
> > > > > +static void clk_regmap_div_init(struct clk_hw *hw)
> > > > > +{
> > > > > + struct clk_regmap *clk = to_clk_regmap(hw);
> > > > > + struct clk_regmap_div_data *div = clk_get_regmap_div_data(clk);
> > > > > + unsigned int val;
> > > > > + int ret;
> > > > > +
> > > > > + ret = regmap_read(clk->map, div->offset, );
> > > > > + if (ret)
> > > > > + return;
> > > > >
> > > > > + val &= (clk_div_mask(div->width) << div->shift);
> > > > > + if (!val)
> > > > > + regmap_update_bits(clk->map, div->offset,
> > > > > +clk_div_mask(div->width) << div->shift,
> > > > > +clk_div_mask(div->width));
> > > >
> > > > This is wrong for several reasons:
> > > > * You should hard code the initial value in the driver.
> > > > * If shift is not 0, I doubt this will give the expected result.
> > >
> > > The value 0x00 of divider means nand clock off then read/write nand
> > > register is forbidden.
> >
> > That is not entirely true, you can access the clock register or you'd be in
> > a
> > chicken and egg situation.
> >
> > > Should we set the initial value in nand driver, or in sub emmc clk driver?
> >
> > In the nand driver, which is the consumer of the clock. see my previous
> > comments
> > about it.
>
> an old version of this series had the code still in the NAND driver
> (by writing to the registers directly instead of using the clk API).
> this looks pretty much like a "sclk-div" to me (as I commented in v3
> of this series: [0]):
> - value 0 means disabled
> - positive divider values
> - (probably no duty control, but that's optional as far as I
> understand sclk-div)
> - uses max divider value when enabling the clock
>
> if switching to sclk-div works then we can get rid of some duplicate code
It is possible:
There is a couple of things to note though:
* sclk does not 'uses max divider value when enabling the clock': Since this
divider can gate, it needs to save the divider value when disabling, since the
divider value is no longer stored in the register,
On init, this cached value is saved as it is. If the divider is initially
disabled, we have to set the cached value to something that makes sense, in case
the clock is enabled without a prior call to clk_set_rate().
So in sclk, the clock setting is not changed nor hard coded in init, and this is
a very important difference.
* Even if sclk zero value means gated, it is still a zero based divider, while
eMMC/Nand divider is one based. It this controller was to sclk, then something
needs to be done for this.
* Since sclk caches a value in its data, and there can multiple instance of eMMC
/NAND clock controller, some care must be taken when registering the data.
Both the generic divider and sclk could work here ... it's up to you Jianxin.
>
>
> Regards
> Martin
>
>
> [0] https://patchwork.kernel.org/patch/10607157/#22238243
Re: drivers by default (was Re: Another HID problem this merge window..)
On Sun, Oct 28, 2018 at 4:16 AM Adam Borowski wrote: > > Amen to that. But, perhaps you could encourage people to do enable drivers > once they become very popular? For example, I just (72a9c673636) got hit by > USB 3.0 being off in defconfigs, and not having keyboard is not that cool. Yes, that seems reasonable. I don't think we need much of an explicit "policy" for these things, though. Things that get _so_ ubiquitous that they should be marked default globally (as opposed to just being in a defconfig file for some board) are pretty rare, and them being "new" things are rarer still. Yeah, usb3 sounds like it would count, but I think that's such a rare exception that I don't think we need to make a policy for it, just a "hey, once or twice in a decade we have a new bus that became so common that we should update the 'default' to y". Linus
Re: [GIT PULL] Kbuild updates for v4.20
On Sun, Oct 28, 2018 at 10:12 AM Masahiro Yamada wrote: > > Please pull Kbuild updates for v4.20 Pulled, Linus
Re: [PATCH v6 1/3] staging: iio: ad2s1210: Switch to the gpio descriptor interface
On Sun, Oct 28, 2018 at 02:36:07PM +, Jonathan Cameron wrote:
> On Sun, 28 Oct 2018 13:21:25 +0530
> Nishad Kamdar wrote:
>
> > Use the gpiod interface instead of the deprecated old non-descriptor
> > interface.
> >
> > Signed-off-by: Nishad Kamdar
> Hi Nishad,
>
> Sorry it took me most of the week to get to this. It's a trade off when you
> want to make fast progress, but I would suggest always leaving a few days
> between patches to see if there are other review comments coming in.
>
Ok, I'll keep that in mind.
> I don't particularly mind myself (as I'm very good at ignoring older versions
> ;)
> but I do feel some time got wasted here on your part.
>
> Anyhow, what you have here is correct but the drive to get things as a nice
> array has lead to a weird mixture of being all array based and not being at
> all.
> Some suggestions in line that will hopefully tidy this up for you.
>
> I'm basically suggesting adding a layer of indirection where you don't
> currently
> have one (on the actual reads and writes) so that you get more consistency
> with the setup code rather than adding a lot of fiddly indirection just in
> the setup code.
>
> Note, what I've given is very much meant to be an illustration. It's probably
> full of bugs and silly naming etc, so don't take it as being right!
>
> Jonathan
>
> > ---
> > drivers/staging/iio/resolver/ad2s1210.c | 92 ++---
> > drivers/staging/iio/resolver/ad2s1210.h | 3 -
> > 2 files changed, 50 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/staging/iio/resolver/ad2s1210.c
> > b/drivers/staging/iio/resolver/ad2s1210.c
> > index ac13b99bd9cb..93c3c70ce62e 100644
> > --- a/drivers/staging/iio/resolver/ad2s1210.c
> > +++ b/drivers/staging/iio/resolver/ad2s1210.c
> > @@ -15,7 +15,7 @@
> > #include
> > #include
> > #include
> > -#include
> > +#include
> > #include
> >
> > #include
> > @@ -69,10 +69,21 @@ enum ad2s1210_mode {
> >
> > static const unsigned int ad2s1210_resolution_value[] = { 10, 12, 14, 16 };
> >
> > +struct ad2s1210_gpio {
> > + struct gpio_desc **ptr;
> > + const char *name;
> > + unsigned long flags;
> > +};
> > +
> > struct ad2s1210_state {
> > const struct ad2s1210_platform_data *pdata;
> > struct mutex lock;
> > struct spi_device *sdev;
>
> With the setup below this becomes
> struct gpio_desc *gpios[5];
>
> > + struct gpio_desc *sample;
> > + struct gpio_desc *a0;
> > + struct gpio_desc *a1;
> > + struct gpio_desc *res0;
> > + struct gpio_desc *res1;
> > unsigned int fclkin;
> > unsigned int fexcit;
> > bool hysteresis;
> > @@ -91,8 +102,8 @@ static const int ad2s1210_mode_vals[4][2] = {
> > static inline void ad2s1210_set_mode(enum ad2s1210_mode mode,
> > struct ad2s1210_state *st)
> > {
> > - gpio_set_value(st->pdata->a[0], ad2s1210_mode_vals[mode][0]);
> > - gpio_set_value(st->pdata->a[1], ad2s1210_mode_vals[mode][1]);
> > + gpiod_set_value(st->a0, ad2s1210_mode_vals[mode][0]);
> > + gpiod_set_value(st->a1, ad2s1210_mode_vals[mode][1]);
> > st->mode = mode;
> > }
> >
> > @@ -152,8 +163,8 @@ int ad2s1210_update_frequency_control_word(struct
> > ad2s1210_state *st)
> >
> > static unsigned char ad2s1210_read_resolution_pin(struct ad2s1210_state
> > *st)
> > {
> > - int resolution = (gpio_get_value(st->pdata->res[0]) << 1) |
> > - gpio_get_value(st->pdata->res[1]);
> > + int resolution = (gpiod_get_value(st->res0) << 1) |
> > + gpiod_get_value(st->res1);
> >
> > return ad2s1210_resolution_value[resolution];
> > }
> > @@ -164,10 +175,10 @@ static const int ad2s1210_res_pins[4][2] = {
> >
> > static inline void ad2s1210_set_resolution_pin(struct ad2s1210_state *st)
> > {
> > - gpio_set_value(st->pdata->res[0],
> > - ad2s1210_res_pins[(st->resolution - 10) / 2][0]);
> > - gpio_set_value(st->pdata->res[1],
> > - ad2s1210_res_pins[(st->resolution - 10) / 2][1]);
> > + gpiod_set_value(st->res0,
> > + ad2s1210_res_pins[(st->resolution - 10) / 2][0]);
> > + gpiod_set_value(st->res1,
> > + ad2s1210_res_pins[(st->resolution - 10) / 2][1]);
> > }
> >
> > static inline int ad2s1210_soft_reset(struct ad2s1210_state *st)
> > @@ -401,15 +412,15 @@ static ssize_t ad2s1210_clear_fault(struct device
> > *dev,
> > int ret;
> >
> > mutex_lock(>lock);
> > - gpio_set_value(st->pdata->sample, 0);
> > + gpiod_set_value(st->sample, 0);
> > /* delay (2 * tck + 20) nano seconds */
> > udelay(1);
> > - gpio_set_value(st->pdata->sample, 1);
> > + gpiod_set_value(st->sample, 1);
> > ret = ad2s1210_config_read(st, AD2S1210_REG_FAULT);
> > if (ret < 0)
> > goto error_ret;
> > - gpio_set_value(st->pdata->sample, 0);
> > - gpio_set_value(st->pdata->sample, 1);
> > + gpiod_set_value(st->sample, 0);
> > +
Re: [PATCH 11/11] perf tools: Stop fallbacking to kallsyms for vdso symbols lookup
On Sat, Oct 27, 2018 at 01:09:44PM -0700, Vinicius Costa Gomes wrote: > Hi Jirka, > > Jiri Olsa writes: > > > On Fri, Oct 26, 2018 at 04:19:52PM -0700, Vinicius Costa Gomes wrote: > >> Hi, > >> > >> Adrian Hunter writes: > >> > >> > On 18/10/18 1:55 AM, Arnaldo Carvalho de Melo wrote: > >> >> From: Arnaldo Carvalho de Melo > >> >> > >> >> David reports that: > >> >> > >> >> > >> >> Perf has this hack where it uses the kernel symbol map as a backup when > >> >> a symbol can't be found in the user's symbol table(s). > >> > > >> > I don't think this is a complete fix because it exposes new problems. > >> > >> This commit broke function name resolution for 'perf record -g' for me. > >> > >> What I mean is, with this commit applied: > >> > >> $ ./tools/perf/perf record -g -- sleep 1 > >> > >> $ ./tools/perf/perf report > >> > >> 'perf report' doesn't seem to be able to show the function names of the > >> trace. > >> > >> If I revert this commit, function names are resolved fine. > > > > that commit just showed up some places where we have the > > ip resolve wrong.. would attached patch fix it for you? > > Thank you for your patch. > > I can some difference in the output, but I wouldn't say that it's fixed. > > Here are some samples, if it's useful somehow: > > https://gist.github.com/vcgomes/985626705e0968b973e426964f86a4b0 > > The "ping" tests were done running > > $ sudo ./tools/perf/perf record -g -- ping -f -c 1000 127.0.0.1 > > And the "sleep" tests were done running > > $ sudo ./tools/perf/perf record -g -- /bin/sleep 1 ugh, I tried with 'sudo ./perf record -g' and it looks like it matter to callchains if there's a workload Adrian said he's preparing complex patch for this let's wait for his changes thanks, jirka
Re: w1: coding style and checkpatch fixes
[ This is not about your patch series per se, only about your email settings ] On Sun, Oct 28, 2018 at 3:20 PM Steffen Vogel wrote: > > This is my first series of patches for the Linux kernel. > I started by familiarizing myself with coding style and > satisfying my inner OCD by cleaning the 1-wire subsystem. Sadly, your DKIM setup is wrong, causing all the emails to be marked as spam when they go through a mailing list. Your DKIM header looks like this: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steffenvogel.de; s=2017; t=1540764601; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; and the problem with that is the "sender" field in there. A good mailing list will not change the contents of your email, or most of the other headers, but it *will* set the sender field to the mailing list. End result: the DKIM signature is guaranteed to fail after the email has gone through a mailing list. In other words, putting the sender field as part of the DKIM-checked headers is just wrong. It's a somewhat common mistake, but it's still wrong. I wonder where people get their setups from, because I think there is some DKIM guide on the internet that is actively spreading this bad behavior. You do have a few other oddities in there (the duplication of the common fields), but they shouldn't matter. Linus
linux-next: manual merge of the vfs tree with the nfsd tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
net/sunrpc/svcsock.c
between commit:
64dbf4dc5496 ("SUNRPC: Simplify TCP receive code")
from the nfsd tree and commit:
aa563d7bca6e ("iov_iter: Separate type from direction and use accessor
functions")
from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/sunrpc/svcsock.c
index 3b525accaa68,0b46ec0bf74e..
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@@ -336,12 -338,8 +336,12 @@@ static ssize_t svc_recvfrom(struct svc_
rqstp->rq_xprt_hlen = 0;
clear_bit(XPT_DATA, >sk_xprt.xpt_flags);
- iov_iter_kvec(_iter, READ | ITER_KVEC, iov, nr, buflen);
+ iov_iter_kvec(_iter, READ, iov, nr, buflen);
- len = sock_recvmsg(svsk->sk_sock, , msg.msg_flags);
+ if (base != 0) {
+ iov_iter_advance(_iter, base);
+ buflen -= base;
+ }
+ len = sock_recvmsg(svsk->sk_sock, , MSG_DONTWAIT);
/* If we read a full record, then assume there may be more
* data to read (stream based sockets only!)
*/
pgp5MJqXpUtEl.pgp
Description: OpenPGP digital signature
Re: [RFR] Store tearing
On Mon, Oct 29, 2018 at 12:10:03AM +0100, Andrea Parri wrote: > Hopefully, with Paul's proper email address this time, > > Andrea > > On Mon, Oct 29, 2018 at 12:06:27AM +0100, Andrea Parri wrote: > > Hi, > > > > memory-barriers.txt says: > > > > [on "store tearing"] > > > > "In fact, a recent bug (since fixed) caused GCC to incorrectly use > >this optimization in a volatile store.". > > > > I was wondering if you could help me retrieve some reference/discussions > > about this? This was quite some time ago, but it involved a 32-bit volatile store of a constant such as 0x10001. The machine in question had a narrow store-immediate instruction, so the compiler emitted a pair of 16-bit store-immediate instructions. This bug was fixed, though only after significant screaming and shouting. Thanx, Paul
Re: [Outreachy kernel] [RESEND PATCH 2/2] staging: vboxvideo: Use unsigned int instead bool
> The "possible alignement issues" in CHECK report is difficult to figure > out by just doing a glance analysis. :) > > Linus also suggested to use bool as the base type i.e., `bool x:1` but > again sizeof(_Bool) is implementation defined ranging from 1-4 bytes. If bool x:1 has the size of bool, then wouldn't int x:1 have the size of int? But my little experiments suggest that the size is the smallest that fits the requested bits and alignment chosen by the compiler, regardless of the type. bool x:1 has the advantage that anything that is not 0 is considered true. So for bool x:1, x = 4 is true, while for int x:1, x = 4 is false. But the :1 adds instructions, so at least for only one bool, where little space is saved, it is probably not worth it. julia
Which SPDX Identifier for files without explicit GPL version
Hi, which GPL version should be used in SPDX Identifiers for files that are GPL licensed but do not mention any version? It is not clear to me after reading license-rules.rst. For example: /** * Copyright(c) 2008 - 2010 Realtek Corporation. All rights reserved. * * 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. * * The full GNU General Public License is included in this distribution in the * file called LICENSE. * * Contact Information: * wlanfae */ or: /* IEEE 802.11 SoftMAC layer * Copyright (c) 2005 Andrea Merello * * Mostly extracted from the rtl8180-sa2400 driver for the * in-kernel generic ieee802.11 stack. * * Some pieces of code might be stolen from ipw2100 driver * copyright of who own it's copyright ;-) * * PS wx handler mostly stolen from hostap, copyright who * own it's copyright ;-) * * released under the GPL */ Should it be GPL-2.0 ? Regards, Michael
Re: [PATCH] mm: simplify get_next_ra_size
On Sun, Oct 28, 2018 at 02:13:26PM +0800, Gao Xiang wrote: > It's a trivial simplification for get_next_ra_size and > clear enough for humans to understand. > > It also fixes potential overflow if ra->size(< ra_pages) is too large. > > Cc: Fengguang Wu > Signed-off-by: Gao Xiang Reviewed-by: Matthew Wilcox I also considered what would happen with underflow (passing a 'max' less than 16, or less than 2) and it would seem to do the right thing in that case.
Re: [PATCH v3] libata: Apply NOLPM quirk for SAMSUNG MZ7TD256HAFV-000L9
Hi, On 28-10-18 05:13, Diego Viola wrote: On Fri, Oct 26, 2018 at 5:36 PM Diego Viola wrote: On Fri, Oct 26, 2018 at 11:21 AM Jens Axboe wrote: On 10/26/18 7:45 AM, Diego Viola wrote: med_power_with_dipm causes my T450 to freeze with a SAMSUNG MZ7TD256HAFV-000L9 SSD (firmware DXT02L5Q). Switching the LPM to max_performance fixes this issue. Applied, thanks. -- Jens Axboe Jens, Hans, Thank you. Diego Hi Hans and Jens, I just wanted to give you guys an update about this problem. I've managed to update my SSD firmware to the latest version[1]. For running the update, I've had to install Windows 10, ran the firmware update, remove Windows and reinstall Arch Linux. The latest version of the firmware is DXT04L5Q, and it looks like there hasn't been a new update since 2015. I'll be running with med_power_with_dipm and hope this firmware update fixes the problem, if it doesn't and I get another freeze, I'll send another patch blacklisting the drive completely. Is that OK? Yes, if it still happens with the latest firmware then blacklisting it completely is the right thing to do. Unfortunately for reasons which I do not understand OEM SSDs often use different (customized?) firmware compared to the model on which they are based and often see less updates and seem to have more bugs :| Regards, Hans
Re: Which SPDX Identifier for files without explicit GPL version
On Sun, Oct 28, 2018 at 11:04:06AM +0100, Michael Straube wrote: > Hi, > > which GPL version should be used in SPDX Identifiers for files that > are GPL licensed but do not mention any version? It is not clear to > me after reading license-rules.rst. > > For example: > > /** > * Copyright(c) 2008 - 2010 Realtek Corporation. All rights reserved. > * > * 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. > * > * The full GNU General Public License is included in this distribution in the > * file called LICENSE. Perhaps look up what version of the GPL that was originally contained in the tarball that this driver was bundled with? I think that should be on their website somewhere... If not, it's v1, not a good thing, but all we have to go on. Also, try emailing: > * Contact Information: > * wlanfae That address :) thanks, greg k-h
Re: [PATCH v3 2/3] iio: adc128s052: add ACPI _HID AANT1280
On Sat, 27 Oct 2018 22:44:28 +0530
Himanshu Jha wrote:
> Hi Dan,
>
> On Thu, Oct 25, 2018 at 04:35:41PM +0100, Dan O'Donovan wrote:
> > From: Nicola Lunghi
> >
> > ACPI _HID AANT1280 matches an ADC124S101 present on E3940 SKUs of the UP
> > Squared board.
> >
> > Add it to the driver.
> >
> > Signed-off-by: Nicola Lunghi
> > [jav...@emutex.com: fix up commit message and one checkpatch warning]
> > Signed-off-by: Javier Arteaga
> > Signed-off-by: Dan O'Donovan
> > ---
> > drivers/iio/adc/ti-adc128s052.c | 18 +-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
>
> []
>
> > +#ifdef CONFIG_ACPI
> > +static const struct acpi_device_id adc128_acpi_match[] = {
> > + { "AANT1280", 2 }, /* ADC124S021 compatible ACPI ID */
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(acpi, adc128_acpi_match);
> > +#endif
>
> I'm curious about the naming conventions used for selecting
> an ACPI ID.
>
> AFAIK, ACPI or PNP ID consists of *Vendor* ID + Product ID.
>
> PNP ID: PNP Vendor IDs consist of 3 characters, each character being
> an uppercase letter (A-Z).
>
> ACPI ID: ACPI Vendor IDs consist of 4 characters, each character being
> either an uppercase letter (A-Z) or a numeral (0-9).
>
> In your case,
>
> Vendor ID -> AANT (AAEON TECHNOLOGY INC. registered ACPI ID prefix)
> http://www.uefi.org/ACPI_ID_List?search=AANT
>
> Product ID -> 1280
>
> How did you come up with 1280 ? And why AANT ? why not TXNW which is
> registered ACPI prefix for TEXAS INSTRUMENTS ?
> http://www.uefi.org/ACPI_ID_List?search=Texas+
Simple answer to that:
TI don't (as far as I know) publish defined ID spaces so no one can
use their ID without risking stepping on an ID in use by someone else.
I would assume there is an AAEON module on this board (pretty common
for embedded boards) so they have assigned an ID from their namespace
as they can know it doesn't clash with anyone else.
>
> Latest ACPI manuals says:
>
> 6.1.5 _HID (Hardware ID)
>
>
> This object is used to supply OSPM with the device’s Plug and Play
> hardware ID.[1]
>
> [1] "A Plug and Play ID or ACPI ID can be obtained by sending e-mail to
> pn...@microsoft.com."
>
> A _HID object evaluates to either a numeric 32-bit compressed EISA type ID or
> a string. If a
> string, the format must be an alphanumeric PNP or ACPI ID with no asterisk or
> other leading
> characters.
>
> A valid PNP ID must be of the form "AAA" where A is an uppercase letter
> and # is a hex
> digit. A valid ACPI ID must be of the form "" where N is an uppercase
> letter or a
> digit ('0'-'9') and # is a hex digit. This specification reserves the string
> "ACPI" for use only
> with devices defined herein. It further reserves all strings representing 4
> HEX digits for
> exclusive use with PCI-assigned Vendor IDs.
>
>
> Next question:
>
> There are a lot drivers in iio/ using ACPI for device enumeration using
> these IDs. For now, let's take an example of Bosch Sensors:
>
> drivers/iio/accel/bmc150-accel-i2c.c:static const struct acpi_device_id
> bmc150_accel_acpi_match[] = {
> drivers/iio/accel/bmc150-accel-i2c.c- {"BSBA0150",bmc150},
> drivers/iio/accel/bmc150-accel-i2c.c- {"BMC150A", bmc150},
> drivers/iio/accel/bmc150-accel-i2c.c- {"BMI055A", bmi055},
> drivers/iio/accel/bmc150-accel-i2c.c- {"BMA0255", bma255},
>
> drivers/iio/gyro/bmg160_i2c.c:static const struct acpi_device_id
> bmg160_acpi_match[] = {
> drivers/iio/gyro/bmg160_i2c.c- {"BMG0160", 0},
> drivers/iio/gyro/bmg160_i2c.c- {"BMI055B", 0},
> drivers/iio/gyro/bmg160_i2c.c- {},
> drivers/iio/gyro/bmg160_i2c.c-};
>
> drivers/iio/imu/bmi160/bmi160_i2c.c:static const struct acpi_device_id
> bmi160_acpi_match[] = {
> drivers/iio/imu/bmi160/bmi160_i2c.c-{"BMI0160", 0},
> drivers/iio/imu/bmi160/bmi160_i2c.c-{ },
> drivers/iio/imu/bmi160/bmi160_i2c.c-};
> drivers/iio/imu/bmi160/bmi160_i2c.c-MODULE_DEVICE_TABLE(acpi,
> bmi160_acpi_match);
>
> Bosch registered ACPI ID: BOSC
> http://www.uefi.org/ACPI_ID_List?search=Bosch
>
> Bosch registered PNP ID: BSG
> http://www.uefi.org/PNP_ID_List?search=Bosch
>
> So, how could we use PNP ID "BMI" which is registered prefix for
> BENSON MEDICAL INSTRUMENTS COMPANY ?
> http://www.uefi.org/PNP_ID_List?search=BMI
>
> Product ID -> "160" is fine for bmi160 which uniquely identifies the
> sensor device.
>
> But shouldn't the prefix be "BSG0160" instead of "BMI0160" ?
>
> When I wrote the driver for Bosch BME680, I followed the same guideline
> as done everywhere else in the Bosch family:
>
> drivers/iio/pressure/bmp280-i2c.c- {"BMP0280", BMP280_CHIP_ID },
> drivers/iio/pressure/bmp280-i2c.c- {"BMP0180", BMP180_CHIP_ID },
> drivers/iio/pressure/bmp280-i2c.c- {"BMP0085", BMP180_CHIP_ID },
> drivers/iio/pressure/bmp280-i2c.c- {"BME0280", BME280_CHIP_ID },
>
> Therefore, I used BME0680 for bosch bme680 sensor!
>
> In OF matching, we use vendor prefixes and that looks
Re: [RFC PATCH v2 01/17] OPP: Allow to request stub voltage regulators
On 10/26/18 6:37 PM, Lucas Stach wrote: > Am Freitag, den 26.10.2018, 15:03 +0300 schrieb Dmitry Osipenko: > [...] >>> On the other hand, the tegra20 cpufreq driver is common across a lot of >>> boards. >>> What will happen if the DT for some of the boards isn't correct and missed >>> the >>> necessary regulator node ? >> >> AFAIK, there is assumption that bootloader should setup regulators in >> a way that kernel could work properly at max clock rates. Otherwise >> things won't work. > > This isn't true. The assumption is that the bootloader sets up the > regulators such that stable operation at the CPU speed used by the > bootloader is guaranteed. > > Often the bootloader doesn't know about specific SKUs, so drives things > at a rate/voltage that is safe across all SKUs [1], in which case the > bootloader is totally unaware of the voltage needed to run the CPU at > highest possible clock frequency. > > Regards, > Lucas > > [1] > http://git.denx.de/?p=u-boot.git;a=commit;h=2364e151e432b4ccf32dc9e6147121253d4ff86d > Oh, okay. Thank you for pointing at [1], though the assumption is true for T20. I agree that it's better not to rely on configuration left from bootloader in general.
Re: [alsa-devel] [PATCH v2] staging: bcm2835-audio: interpolate audio delay
> On 25 Oct 2018, at 08:37, Takashi Iwai wrote: > > On Thu, 25 Oct 2018 00:02:34 +0200, > Kirill Marinushkin wrote: >> When you play sound - the pointer increments. >>> >>> Unfortunately, when you play sound, the pointer does not actually >>> increment, for up to about 10 milliseconds. I know of no way to actually >>> access the true “live” position of the frame that is being played at any >>> instant; hence the desire to estimate it. >>> >> >> Your vision of situation in the opposite from my vision. What you see as a >> symptom - I see as a root cause. As I see, you should fix the >> pointer-not-incrementing. Why do you think that it's okay that the pointer is >> not updating during sound play? Why do you insist that there is a delay? I >> don't >> understand why we are so stuck here. > > Well, in the API POV, it's nothing wrong to keep hwptr sticking while > updating only delay value. It implies that the hardware chip doesn't > provide the hwptr update. > > Though, usually the delay value is provided also from the hardware, > e.g. reading the link position or such. It's a typical case like > USB-audio, where the hwptr gets updated and the delay indicates the > actual position *behind* hwptr. That works because hwptr shows the > position in the ring buffer at which you can access the data. And it > doesn't mean that hwptr is the actually playing position, but it can > be ahead of the current position, when many samples are queued on > FIFO. The delay is provided to correct the position back to the > actual point. > > But, this also doesn't mean that the delay shouldn't be used for the > purpose like this patchset, either. OTOH, providing a finer hwptr > value would be likely more apps-friendly; there must be many programs > that don't evaluate the delay value properly. > > So, I suppose that hwptr update might be a better option if the code > won't become too complex. Let's see. Indeed. It will take me a few days to look into this… Regards Mike > One another thing I'd like to point out is that the value given in the > patch is nothing but an estimated position, optimistically calculated > via the system timer. Mike and I had already discussion in another > thread, and another possible option would be to provide the proper > timestamp-vs-hwptr pair, instead of updating the timestamp always at > the status read. > > Maybe it's worth to have a module option to suppress this optimistic > hwptr update behavior, in case something went wrong with clocks? > > > thanks, > > Takashi
Re: [alsa-devel] [PATCH v2] staging: bcm2835-audio: interpolate audio delay
Hi Kirill. Thanks for the post. Mike > On 25 Oct 2018, at 18:20, Kirill Marinushkin wrote: > > Hello Takashi, Mike, > > @Takashi > > On 10/25/18 09:37, Takashi Iwai wrote: >> Well, in the API POV, it's nothing wrong to keep hwptr sticking while >> updating only delay value. It implies that the hardware chip doesn't >> provide the hwptr update. > > Thank you for the clarification. Modifying `runtime->delay` from the `pointer` > function looked wrong for me. Now I understand the motivation and the > use-case. > I will be more careful when analyzing the code which doesn't fit my > expectations. > > @Mike > > I was wrong. You can ignore my comments. Please don't take them personal: it's > all about having high-quality code in kernel. > > Best Regards, > Kirill > ___ > Alsa-devel mailing list > alsa-de...@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Re: [PATCH v6 3/3] staging: iio: ad2s1210: Add device tree support.
On Sun, 28 Oct 2018 13:23:23 +0530
Nishad Kamdar wrote:
> Replace platform data with device tree support.
>
> Signed-off-by: Nishad Kamdar
The whole gpio in or out thing makes less and less sense to
me and seems to contradict the datasheet.
If I'm not missing something I would just get rid of the option.
If I am missing something (not hard in the datasheet which, whilst
fairly clear, is a rather long ;)
Jonathan
> ---
> drivers/staging/iio/resolver/Kconfig| 1 +
> drivers/staging/iio/resolver/ad2s1210.c | 17 -
> drivers/staging/iio/resolver/ad2s1210.h | 17 -
> 3 files changed, 9 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/staging/iio/resolver/Kconfig
> b/drivers/staging/iio/resolver/Kconfig
> index 6a469ee6101f..cc1202ff813d 100644
> --- a/drivers/staging/iio/resolver/Kconfig
> +++ b/drivers/staging/iio/resolver/Kconfig
> @@ -15,6 +15,7 @@ config AD2S90
>
> config AD2S1210
> tristate "Analog Devices ad2s1210 driver"
> + depends on OF
> depends on SPI
> depends on GPIOLIB || COMPILE_TEST
> help
> diff --git a/drivers/staging/iio/resolver/ad2s1210.c
> b/drivers/staging/iio/resolver/ad2s1210.c
> index 0234869e9d74..5ecdb5785132 100644
> --- a/drivers/staging/iio/resolver/ad2s1210.c
> +++ b/drivers/staging/iio/resolver/ad2s1210.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -76,7 +77,6 @@ struct ad2s1210_gpio {
> };
>
> struct ad2s1210_state {
> - const struct ad2s1210_platform_data *pdata;
> struct mutex lock;
> struct spi_device *sdev;
> struct gpio_desc *sample;
> @@ -84,6 +84,7 @@ struct ad2s1210_state {
> struct gpio_desc *a1;
> struct gpio_desc *res0;
> struct gpio_desc *res1;
> + bool gpioin;
> unsigned int fclkin;
> unsigned int fexcit;
> bool hysteresis;
> @@ -314,7 +315,7 @@ static ssize_t ad2s1210_store_control(struct device *dev,
> }
> st->resolution
> = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
> - if (st->pdata->gpioin) {
> + if (st->gpioin) {
> data = ad2s1210_read_resolution_pin(st);
> if (data != st->resolution)
> dev_warn(dev, "ad2s1210: resolution settings not
> match\n");
> @@ -376,7 +377,7 @@ static ssize_t ad2s1210_store_resolution(struct device
> *dev,
> }
> st->resolution
> = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
> - if (st->pdata->gpioin) {
> + if (st->gpioin) {
> data = ad2s1210_read_resolution_pin(st);
> if (data != st->resolution)
> dev_warn(dev, "ad2s1210: resolution settings not
> match\n");
> @@ -603,7 +604,7 @@ static int ad2s1210_initial(struct ad2s1210_state *st)
> int ret;
>
> mutex_lock(>lock);
> - if (st->pdata->gpioin)
> + if (st->gpioin)
> st->resolution = ad2s1210_read_resolution_pin(st);
> else
> ad2s1210_set_resolution_pin(st);
> @@ -644,7 +645,7 @@ static int ad2s1210_setup_gpios(struct ad2s1210_state *st)
> int ret, i;
> struct spi_device *spi = st->sdev;
> struct ad2s1210_gpio *pin;
> - unsigned long flags = st->pdata->gpioin ? GPIOD_IN : GPIOD_OUT_LOW;
> + unsigned long flags = st->gpioin ? GPIOD_IN : GPIOD_OUT_LOW;
>
> struct ad2s1210_gpio gpios[] = {
> { .ptr = >sample, .name = "sample", .flags = GPIOD_IN },
> @@ -673,16 +674,14 @@ static int ad2s1210_probe(struct spi_device *spi)
> {
> struct iio_dev *indio_dev;
> struct ad2s1210_state *st;
> + struct device_node *np = spi->dev.of_node;
> int ret;
>
> - if (!spi->dev.platform_data)
> - return -EINVAL;
> -
> indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
> if (!indio_dev)
> return -ENOMEM;
> st = iio_priv(indio_dev);
> - st->pdata = spi->dev.platform_data;
> + st->gpioin = of_property_read_bool(np, "gpioin");
Hmm. This bothered me in the earlier patch. How are we meant to configure
these pins... (and this time I actually loaded the datasheet)
A0 and A1 always seem to be control signals written to the device so
I don't really understand why we would ever want them to be 'inputs'
on our host.
RES0 and RES1 are also control signals. Clearly marked as logic inputs.
The only thing I can think here is there is an evaluation board out there
were we are not in control of these, some other controller is.
That is a pretty weird board if so, hence I would only support the version
where we use GPIO outputs from the host.
This will further simplify patch 1 and get rid fo the need for this
non standard bit of devicetree binding.
> ret = ad2s1210_setup_gpios(st);
> if (ret < 0)
> return ret;
> diff --git a/drivers/staging/iio/resolver/ad2s1210.h
>
Re: [PATCH v2] pstore: Avoid duplicate call of persistent_ram_zap()
On Sat, Oct 27, 2018 at 2:08 PM, Peng15 Wang 王鹏 wrote:
> When initialing prz with invalid data in buffer(no PERSISTENT_RAM_SIG),
> function call path is like this:
>
> ramoops_init_prz ->
> |
> |-> persistent_ram_new -> persistent_ram_post_init -> persistent_ram_zap
> |
> |-> persistent_ram_zap
>
> As we can see, persistent_ram_zap() is called twice.
> We can avoid this by adding an option to persistent_ram_new(), and
> only call persistent_ram_zap() when it is needed.
>
> Signed-off-by: Peng Wang
> ---
> fs/pstore/ram.c| 5 +++--
> fs/pstore/ram_core.c | 11 +++
> include/linux/pstore_ram.h | 3 ++-
> 3 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index ffcff6516e89..3044274de2f0 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -596,7 +596,8 @@ static int ramoops_init_przs(const char *name,
> name, i, *cnt - 1);
> prz_ar[i] = persistent_ram_new(*paddr, zone_sz, sig,
>>ecc_info,
> - cxt->memtype, flags, label);
> + cxt->memtype, flags,
> + label, true);
> if (IS_ERR(prz_ar[i])) {
> err = PTR_ERR(prz_ar[i]);
> dev_err(dev, "failed to request %s mem region
> (0x%zx@0x%llx): %d\n",
> @@ -640,7 +641,7 @@ static int ramoops_init_prz(const char *name,
>
> label = kasprintf(GFP_KERNEL, "ramoops:%s", name);
> *prz = persistent_ram_new(*paddr, sz, sig, >ecc_info,
> - cxt->memtype, 0, label);
> + cxt->memtype, 0, label, false);
> if (IS_ERR(*prz)) {
> int err = PTR_ERR(*prz);
>
> diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
> index 12e21f789194..d8a520c8741c 100644
> --- a/fs/pstore/ram_core.c
> +++ b/fs/pstore/ram_core.c
> @@ -486,7 +486,8 @@ static int persistent_ram_buffer_map(phys_addr_t start,
> phys_addr_t size,
> }
>
> static int persistent_ram_post_init(struct persistent_ram_zone *prz, u32 sig,
> - struct persistent_ram_ecc_info *ecc_info)
> + struct persistent_ram_ecc_info *ecc_info,
> + bool zap_option)
> {
> int ret;
>
> @@ -514,7 +515,8 @@ static int persistent_ram_post_init(struct
> persistent_ram_zone *prz, u32 sig,
>
> /* Rewind missing or invalid memory area. */
> prz->buffer->sig = sig;
> - persistent_ram_zap(prz);
> + if (zap_option)
> + persistent_ram_zap(prz);
This part of persistent_ram_post_init() handles the "invalid buffer"
case, which should always zap. The question is whether or not to zap
in the case of a valid buffer (the "return 0" earlier in the
function). I think you v2 patch needs similar changes found in your
v1: the v2 patch also needs to remove the "return 0" and replace it
with "zap_option = true;" and to remove the zap call from
ramoops_init_prz(). Then I think all the paths will be consolidated.
-Kees
>
> return 0;
> }
> @@ -548,7 +550,8 @@ void persistent_ram_free(struct persistent_ram_zone *prz)
>
> struct persistent_ram_zone *persistent_ram_new(phys_addr_t start, size_t
> size,
> u32 sig, struct persistent_ram_ecc_info *ecc_info,
> - unsigned int memtype, u32 flags, char *label)
> + unsigned int memtype, u32 flags, char *label,
> + bool zap_option)
> {
> struct persistent_ram_zone *prz;
> int ret = -ENOMEM;
> @@ -568,7 +571,7 @@ struct persistent_ram_zone
> *persistent_ram_new(phys_addr_t start, size_t size,
> if (ret)
> goto err;
>
> - ret = persistent_ram_post_init(prz, sig, ecc_info);
> + ret = persistent_ram_post_init(prz, sig, ecc_info, zap_option);
> if (ret)
> goto err;
>
> diff --git a/include/linux/pstore_ram.h b/include/linux/pstore_ram.h
> index 602d64725222..5d4acad9fe56 100644
> --- a/include/linux/pstore_ram.h
> +++ b/include/linux/pstore_ram.h
> @@ -66,7 +66,8 @@ struct persistent_ram_zone {
>
> struct persistent_ram_zone *persistent_ram_new(phys_addr_t start, size_t
> size,
> u32 sig, struct persistent_ram_ecc_info *ecc_info,
> - unsigned int memtype, u32 flags, char *label);
> + unsigned int memtype, u32 flags, char *label,
> + bool zap_option);
> void persistent_ram_free(struct persistent_ram_zone *prz);
> void persistent_ram_zap(struct persistent_ram_zone *prz);
>
> --
> 2.19.1
--
Kees Cook
Build regressions/improvements in v4.19
Below is the list of build error/warning regressions/improvements in
v4.19[1] compared to v4.18[2].
Summarized:
- build errors: +5/-3
- build warnings: +14715/-247
JFYI, when comparing v4.19[1] to v4.19-rc8[3], the summaries are:
- build errors: +0/-0
- build warnings: +158/-166
Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.
Happy fixing! ;-)
Thanks to the linux-next team for providing the build service.
[1]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d/
(all 240 configs)
[2]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/94710cac0ef4ee177a63b5227664b38c95bbf703/
(239 out of 240 configs)
[3]
http://kisskb.ellerman.id.au/kisskb/branch/linus/head/35a7f35ad1b150ddf59a41dcac7b2fa32982be0e/
(all 240 configs)
*** ERRORS ***
5 error regressions:
+ error: arch/sparc/kernel/.tmp_head_32.o: relocation truncated to fit:
R_SPARC_WDISP22 against `.init.text': => (.head.text+0x5100),
(.head.text+0x5040)
+ error: arch/sparc/kernel/.tmp_head_32.o: relocation truncated to fit:
R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section
in arch/sparc/kernel/trampoline_32.o: => (.init.text+0xa4)
+ error: arch/sparc/kernel/process_32.o: relocation truncated to fit:
R_SPARC_WDISP22 against `.text': => (.fixup+0xc), (.fixup+0x4)
+ error: arch/sparc/kernel/signal_32.o: relocation truncated to fit:
R_SPARC_WDISP22 against `.text': => (.fixup+0x8), (.fixup+0x10),
(.fixup+0x20), (.fixup+0x18), (.fixup+0x0)
+ error: ene_ub6250.c: relocation truncated to fit: R_NDS32_9_PCREL_RELA
against `.text': => (.text+0x284)
3 error improvements:
- error: "__sanitizer_cov_trace_cmpd" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
undefined!: N/A =>
- error: "__sanitizer_cov_trace_cmpf" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
undefined!: N/A =>
- error: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!: N/A
=>
*** WARNINGS ***
[Deleted 14577 lines about "warning: -ffunction-sections disabled; it makes
profiling impossible [enabled by default]" on powerpc-all{mod,yes}config*]
14715 warning regressions:
+ /kisskb/src/arch/alpha/kernel/osf_sys.c: warning: unused variable 'err'
[-Wunused-variable]: => 563:11
+ /kisskb/src/arch/alpha/kernel/osf_sys.c: warning: unused variable 'error'
[-Wunused-variable]: => 532:6
+ /kisskb/src/arch/arc/include/asm/cmpxchg.h: warning: value computed is not
used [-Wunused-value]: => 95:29
+ /kisskb/src/arch/mips/include/asm/sibyte/bcm1480_scd.h: warning:
"M_SPC_CFG_CLEAR" redefined: 274:0 => 274:0, 274
+ /kisskb/src/arch/mips/include/asm/sibyte/bcm1480_scd.h: warning:
"M_SPC_CFG_ENABLE" redefined: 275:0 => 275:0, 275
+ /kisskb/src/arch/powerpc/include/asm/io.h: warning: 'px_cmd' may be used
uninitialized in this function [-Wmaybe-uninitialized]: => 160:2
+ /kisskb/src/arch/powerpc/include/asm/io.h: warning: 'px_is' may be used
uninitialized in this function [-Wmaybe-uninitialized]: => 160:2
+ /kisskb/src/arch/s390/mm/pgtable.c: warning: 'pmd_alloc_map' defined but
not used [-Wunused-function]: => 413:15
+
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:
warning: (near initialization for 'blnd_cfg.black_color') [-Wmissing-braces]:
=> 1903:9
+
/kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:
warning: missing braces around initializer [-Wmissing-braces]: => 1903:9
+ /kisskb/src/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c: warning: (near
initialization for 'task_info.process_name') [-Wmissing-braces]: => 1447:10
+ /kisskb/src/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c: warning: missing braces
around initializer [-Wmissing-braces]: => 1447:10
+ /kisskb/src/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c: warning: (near
initialization for 'task_info.process_name') [-Wmissing-braces]: => 262:10
+ /kisskb/src/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c: warning: missing braces
around initializer [-Wmissing-braces]: => 262:10
+ /kisskb/src/drivers/gpu/drm/drm_atomic.c: warning: 'crtc_state' may be used
uninitialized in this function [-Wuninitialized]: => 765:38
+ /kisskb/src/drivers/gpu/drm/drm_atomic.c: warning: format '%zu' expects
argument of type 'size_t', but argument 5 has type 'unsigned int' [-Wformat=]:
=> 441:21
+ /kisskb/src/drivers/i2c/i2c-core-base.c: warning: 'ret' may be used
uninitialized in this function [-Wmaybe-uninitialized]: => 235:5
+ /kisskb/src/drivers/i2c/i2c-core-base.c: warning: 'ret' may be used
uninitialized in this function [-Wuninitialized]: => 235:5
+ /kisskb/src/drivers/iio/proximity/isl29501.c: warning: 'msb' may be used
uninitialized in this function [-Wuninitialized]: => 253:34, 253:7
+ /kisskb/src/drivers/md/dm-crypt.c: warning: 'crypt_iv_lmk_one.isra.26' uses
dynamic stack allocation [enabled by default]: => 645:1
+ /kisskb/src/drivers/md/dm-crypt.c: warning:
[PATCH v6 0/3] staging: iio: ad2s1210: Switch to the gpio descriptor interface.
Use the gpiod interface instead of the deprecated old non-descriptor
Changes in v6:
- Split device tree table addition and device tree support
addition in two patches.
- Replace platform data with device tree support.
- Rename boolean property.
Changes in v5:
- Add device tree support.
- Add device tree table for matching vendor ID.
- Add Support for retrieving platform data from device tree.
Changes in v4:
- Add spaces after { and before } in gpios[]
initialization.
- Check the correct pointer for error.
- Align the dev_err msg to existing format in the code.
Changes in v3:
- Use a pointer to pointer for gpio_desc in
struct ad2s1210_gpio as it will be used to
modify a pointer.
- Use dot notation to initialize the structure.
- Use a pointer variable to avoid writing gpios[i].
Changes in v2:
- Use the spi_device struct embedded in st instead
of passing it as an argument to ad2s1210_setup_gpios().
- Use an array of structs to reduce redundant code in
in ad2s1210_setup_gpios().
- Remove ad2s1210_free_gpios() as devm API is being used.
-
Nishad Kamdar (3):
staging: iio: ad2s1210: Switch to the gpio descriptor interface
staging: iio: ad2s1210: Add device tree table.
staging: iio: ad2s1210: Add device tree support.
drivers/staging/iio/resolver/Kconfig| 1 +
drivers/staging/iio/resolver/ad2s1210.c | 114 +---
drivers/staging/iio/resolver/ad2s1210.h | 20 -
3 files changed, 65 insertions(+), 70 deletions(-)
--
2.17.1
[PATCH v6 1/3] staging: iio: ad2s1210: Switch to the gpio descriptor interface
Use the gpiod interface instead of the deprecated old non-descriptor
interface.
Signed-off-by: Nishad Kamdar
---
drivers/staging/iio/resolver/ad2s1210.c | 92 ++---
drivers/staging/iio/resolver/ad2s1210.h | 3 -
2 files changed, 50 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/iio/resolver/ad2s1210.c
b/drivers/staging/iio/resolver/ad2s1210.c
index ac13b99bd9cb..93c3c70ce62e 100644
--- a/drivers/staging/iio/resolver/ad2s1210.c
+++ b/drivers/staging/iio/resolver/ad2s1210.c
@@ -15,7 +15,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -69,10 +69,21 @@ enum ad2s1210_mode {
static const unsigned int ad2s1210_resolution_value[] = { 10, 12, 14, 16 };
+struct ad2s1210_gpio {
+ struct gpio_desc **ptr;
+ const char *name;
+ unsigned long flags;
+};
+
struct ad2s1210_state {
const struct ad2s1210_platform_data *pdata;
struct mutex lock;
struct spi_device *sdev;
+ struct gpio_desc *sample;
+ struct gpio_desc *a0;
+ struct gpio_desc *a1;
+ struct gpio_desc *res0;
+ struct gpio_desc *res1;
unsigned int fclkin;
unsigned int fexcit;
bool hysteresis;
@@ -91,8 +102,8 @@ static const int ad2s1210_mode_vals[4][2] = {
static inline void ad2s1210_set_mode(enum ad2s1210_mode mode,
struct ad2s1210_state *st)
{
- gpio_set_value(st->pdata->a[0], ad2s1210_mode_vals[mode][0]);
- gpio_set_value(st->pdata->a[1], ad2s1210_mode_vals[mode][1]);
+ gpiod_set_value(st->a0, ad2s1210_mode_vals[mode][0]);
+ gpiod_set_value(st->a1, ad2s1210_mode_vals[mode][1]);
st->mode = mode;
}
@@ -152,8 +163,8 @@ int ad2s1210_update_frequency_control_word(struct
ad2s1210_state *st)
static unsigned char ad2s1210_read_resolution_pin(struct ad2s1210_state *st)
{
- int resolution = (gpio_get_value(st->pdata->res[0]) << 1) |
- gpio_get_value(st->pdata->res[1]);
+ int resolution = (gpiod_get_value(st->res0) << 1) |
+ gpiod_get_value(st->res1);
return ad2s1210_resolution_value[resolution];
}
@@ -164,10 +175,10 @@ static const int ad2s1210_res_pins[4][2] = {
static inline void ad2s1210_set_resolution_pin(struct ad2s1210_state *st)
{
- gpio_set_value(st->pdata->res[0],
- ad2s1210_res_pins[(st->resolution - 10) / 2][0]);
- gpio_set_value(st->pdata->res[1],
- ad2s1210_res_pins[(st->resolution - 10) / 2][1]);
+ gpiod_set_value(st->res0,
+ ad2s1210_res_pins[(st->resolution - 10) / 2][0]);
+ gpiod_set_value(st->res1,
+ ad2s1210_res_pins[(st->resolution - 10) / 2][1]);
}
static inline int ad2s1210_soft_reset(struct ad2s1210_state *st)
@@ -401,15 +412,15 @@ static ssize_t ad2s1210_clear_fault(struct device *dev,
int ret;
mutex_lock(>lock);
- gpio_set_value(st->pdata->sample, 0);
+ gpiod_set_value(st->sample, 0);
/* delay (2 * tck + 20) nano seconds */
udelay(1);
- gpio_set_value(st->pdata->sample, 1);
+ gpiod_set_value(st->sample, 1);
ret = ad2s1210_config_read(st, AD2S1210_REG_FAULT);
if (ret < 0)
goto error_ret;
- gpio_set_value(st->pdata->sample, 0);
- gpio_set_value(st->pdata->sample, 1);
+ gpiod_set_value(st->sample, 0);
+ gpiod_set_value(st->sample, 1);
error_ret:
mutex_unlock(>lock);
@@ -466,7 +477,7 @@ static int ad2s1210_read_raw(struct iio_dev *indio_dev,
s16 vel;
mutex_lock(>lock);
- gpio_set_value(st->pdata->sample, 0);
+ gpiod_set_value(st->sample, 0);
/* delay (6 * tck + 20) nano seconds */
udelay(1);
@@ -512,7 +523,7 @@ static int ad2s1210_read_raw(struct iio_dev *indio_dev,
}
error_ret:
- gpio_set_value(st->pdata->sample, 1);
+ gpiod_set_value(st->sample, 1);
/* delay (2 * tck + 20) nano seconds */
udelay(1);
mutex_unlock(>lock);
@@ -630,30 +641,32 @@ static const struct iio_info ad2s1210_info = {
static int ad2s1210_setup_gpios(struct ad2s1210_state *st)
{
- unsigned long flags = st->pdata->gpioin ? GPIOF_DIR_IN : GPIOF_DIR_OUT;
- struct gpio ad2s1210_gpios[] = {
- { st->pdata->sample, GPIOF_DIR_IN, "sample" },
- { st->pdata->a[0], flags, "a0" },
- { st->pdata->a[1], flags, "a1" },
- { st->pdata->res[0], flags, "res0" },
- { st->pdata->res[0], flags, "res1" },
+ int ret, i;
+ struct spi_device *spi = st->sdev;
+ struct ad2s1210_gpio *pin;
+ unsigned long flags = st->pdata->gpioin ? GPIOD_IN : GPIOD_OUT_LOW;
+
+ struct ad2s1210_gpio gpios[] = {
+ { .ptr = >sample, .name = "sample", .flags = GPIOD_IN },
+ { .ptr = >a0, .name = "a0", .flags = flags },
+
Re: [Outreachy kernel] [RESEND PATCH 2/2] staging: vboxvideo: Use unsigned int instead bool
On Sun, Oct 28, 2018 at 09:47:15AM +0100, Julia Lawall wrote:
> > The "possible alignement issues" in CHECK report is difficult to figure
> > out by just doing a glance analysis. :)
> >
> > Linus also suggested to use bool as the base type i.e., `bool x:1` but
> > again sizeof(_Bool) is implementation defined ranging from 1-4 bytes.
>
> If bool x:1 has the size of bool, then wouldn't int x:1 have the size of
> int? But my little experiments suggest that the size is the smallest that
> fits the requested bits and alignment chosen by the compiler, regardless of
> the type.
Yes, correct!
And we can't use sizeof on bitfields *directly*, nor reference it using a
pointer.
It can be applied only when these bitfields are wrapped in a structure.
Testing:
#include
#include
struct S {
bool a:1;
bool b:1;
bool c:1;
bool d:1;
};
int main(void)
{
printf("%zu\n", sizeof(struct S));
}
Output: 1
If I change all bool to unsigned int, output is: *4*.
So, conclusion is compiler doesn't squeeze the size less than
native size of the datatype i.e., if we changed all members to
unsigned int:1,
total width = 4 bits
padding = 4 bits
Therefore, total size should have been = 1 byte!
But since sizeof(unsigned int) == 4, it can't be squeezed to
less than it.
> bool x:1 has the advantage that anything that is not 0 is considered true.
Yes, implicit conversion rules for boolean.
> So for bool x:1, x = 4 is true, while for int x:1, x = 4 is false.
Well, int x:1 can either have 0..1 or -1..0 range due implementation
defined behavior as I said in the previous reply.
If you really want to consider negative values, then make it explicit
using `signed int x:1` which make range guaranteed to be -1..0
Regardless, integer conversion rules will kick in.
> But the :1 adds instructions, so at least for only one bool, where little
> space is saved, it is probably not worth it.
True, we should reply on a promised guideline rather than possibility.
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology
