Re: [PATCH 8/9] bcache: use kvmalloc
On 01/30/2017 10:49 AM, Michal Hocko wrote: From: Michal Hocko bcache_device_init uses kmalloc for small requests and vmalloc for those which are larger than 64 pages. This alone is a strange criterion. Moreover kmalloc can fallback to vmalloc on the failure. Let's simply use kvmalloc instead as it knows how to handle the fallback properly I don't see why separate patch, some of the conversions in 5/9 were quite similar (except comparing with PAGE_SIZE, not 64*PAGE_SIZE), but nevermind. Cc: Kent Overstreet Signed-off-by: Michal Hocko Acked-by: Vlastimil Babka --- drivers/md/bcache/super.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c index 3a19cbc8b230..4cb6b88a1465 100644 --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -767,16 +767,12 @@ static int bcache_device_init(struct bcache_device *d, unsigned block_size, } n = d->nr_stripes * sizeof(atomic_t); - d->stripe_sectors_dirty = n < PAGE_SIZE << 6 - ? kzalloc(n, GFP_KERNEL) - : vzalloc(n); + d->stripe_sectors_dirty = kvzalloc(n, GFP_KERNEL); if (!d->stripe_sectors_dirty) return -ENOMEM; n = BITS_TO_LONGS(d->nr_stripes) * sizeof(unsigned long); - d->full_dirty_stripes = n < PAGE_SIZE << 6 - ? kzalloc(n, GFP_KERNEL) - : vzalloc(n); + d->full_dirty_stripes = kvzalloc(n, GFP_KERNEL); if (!d->full_dirty_stripes) return -ENOMEM;
Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM
On 01/29/2017 03:09 PM, Boris Ostrovsky wrote: There are couple of problems with this patch. 1. The 'if' clause now evaluates to true on pretty much every call to xennet_alloc_rx_buffers(). Thanks for catching this. In my testing I did not notice this - mostly because of the nature of the workload in my testing. 2. It tickles a latent bug during resume where the timer triggers before we re-connect. The trouble is that we now try to dereference queue->rx.sring which is NULL since we disconnect in netfront_resume(). (Curiously, I only observe it with 32-bit guests) I think we may hit this bug after removing the timer as well. We call RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference queue->rx.sring. Thanks, Vineeth
[PATCH] spi: fix device-node leaks
Make sure to release the device-node reference taken in
of_register_spi_device() on errors and when deregistering the device.
Fixes: 284b01897340 ("spi: Add OF binding support for SPI busses")
Signed-off-by: Johan Hovold
---
drivers/spi/spi.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 656dd3e3220c..730e3c9794db 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -621,8 +621,10 @@ void spi_unregister_device(struct spi_device *spi)
if (!spi)
return;
- if (spi->dev.of_node)
+ if (spi->dev.of_node) {
of_node_clear_flag(spi->dev.of_node, OF_POPULATED);
+ of_node_put(spi->dev.of_node);
+ }
if (ACPI_COMPANION(&spi->dev))
acpi_device_clear_enumerated(ACPI_COMPANION(&spi->dev));
device_unregister(&spi->dev);
@@ -1603,11 +1605,13 @@ of_register_spi_device(struct spi_master *master,
struct device_node *nc)
if (rc) {
dev_err(&master->dev, "spi_device register error %s\n",
nc->full_name);
- goto err_out;
+ goto err_of_node_put;
}
return spi;
+err_of_node_put:
+ of_node_put(nc);
err_out:
spi_dev_put(spi);
return ERR_PTR(rc);
--
2.10.2
Re: [PATCH v3 08/10] dmaengine: sun6i: allow build on ARM64 platforms (sun50i)
On Sun, Jan 29, 2017 at 10:33:29AM +0800, Icenowy Zheng wrote: > As 64-bit Allwinner H5 SoC has the same DMA engine with H3, the DMA > driver should be allowed to be built for ARM64, in order to make it work on > H5. > > Signed-off-by: Icenowy Zheng > Acked-by: Maxime Ripard > Acked-by: Chen-Yu Tsai > --- > Patch introduced between v1 and v2, to satisfy the newly added H3/H5 audio > codec support. > > drivers/dma/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig > index 0d6a96ee9fc7..d01d59812cf3 100644 > --- a/drivers/dma/Kconfig > +++ b/drivers/dma/Kconfig > @@ -157,7 +157,7 @@ config DMA_SUN4I > > config DMA_SUN6I > tristate "Allwinner A31 SoCs DMA support" > - depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST > + depends on MACH_SUN6I || MACH_SUN8I || (ARM64 && ARCH_SUNXI) || > COMPILE_TEST Do we really need ARM64 here? also looking at others I wonder why isn't this MACH_SUNXI...? -- ~Vinod
Re: [PATCH 1/2] dt-bindings: Document the VC4 DSI module nodes.
On Fri, Jan 27, 2017 at 8:41 PM, Eric Anholt wrote: > Rob Herring writes: > >> Need to cc DT list if you want it in my queue. >> >> On Mon, Jan 23, 2017 at 6:38 PM, Eric Anholt wrote: >>> These are part of the vc4 display pipeline. >>> >>> Signed-off-by: Eric Anholt >>> --- >>> .../devicetree/bindings/display/brcm,bcm-vc4.txt | 35 >>> ++ >>> 1 file changed, 35 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >>> b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >>> index e2768703ac2b..34c7fddcea39 100644 >>> --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >>> +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >>> @@ -56,6 +56,18 @@ Required properties for V3D: >>> - interrupts: The interrupt number >>> See >>> bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt >>> >>> +Required properties for DSI: >>> +- compatible: Should be "brcm,bcm2835-dsi0" or "brcm,bcm2835-dsi1" >> >> Are the blocks different? > > They are from the same lineage, but very different (old dsi0 is 1 lane, > dsi1 is 4 lanes). You can see how much the registers move around and > change in the dsi->port conditional blocks in the driver code. Okay, can you add a note here with this detail. With that, Acked-by: Rob Herring
Re: [PATCH] Dma - Fix possible NULL derefrence.
On Fri, Jan 27, 2017 at 04:55:59PM +0530, Shailendra Verma wrote:
> of_match_device could return NULL, and so cause a NULL
> pointer dereference later.
Why is this tagged Dma -
Please look at he git log for the file before coming up with random tags
Worst part, this patch fails to apply, so which was this generated against?
>
> Signed-off-by: Shailendra Verma
> ---
> drivers/dma/mv_xor.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
> index 23f7528..c25b3bb 100644
> --- a/drivers/dma/mv_xor.c
> +++ b/drivers/dma/mv_xor.c
> @@ -1323,7 +1323,10 @@ static int mv_xor_probe(struct platform_device *pdev)
> const struct of_device_id *of_id =
> of_match_device(mv_xor_dt_ids,
> &pdev->dev);
> + if (!of_id) {
> + dev_err(&pdev->dev, "Error: No device match found\n");
> + return -ENODEV;
> + }
> xordev->xor_type = (uintptr_t)of_id->data;
> }
>
> --
> 1.7.9.5
>
--
~Vinod
Re: [PATCH] PCI: mvebu: Handle changes to the bridge windows while enabled
On Mon, Jan 30, 2017 at 09:41:36AM -0600, Bjorn Helgaas wrote: > On Mon, Dec 12, 2016 at 11:30:20AM -0700, Jason Gunthorpe wrote: > > The PCI core will write to the bridge window config multiple times > > while they are enabled. This can lead to mbus failures like: > > > > mvebu_mbus: cannot add window '4:e8', conflicts with another window > > mvebu-pcie mbus:pex@e000: Could not create MBus window at [mem > > 0xe000-0xe00f]: -22 > > > > For me this is happening during a hotplug cycle. The PCI core is > > not changing the values, just writing them twice while active. > > > > The patch addresses the general case of any change to an active window, > > but not atomically. The code is slightly refactored so io and mem > > can share more of the window logic. > > > > Signed-off-by: Jason Gunthorpe > > Applied with Jason C's ack to pci/host-mvebu for v4.11, thanks! Thank you for keeping on top of this Bjorn! Jason
Re: [PATCH RESEND 2/5] dmaengine: Provide a wrapper for memcpy operations
On Fri, Jan 27, 2017 at 05:42:01PM +0100, Boris Brezillon wrote: > Almost all ->device_prep_dma_xx() methods have a wrapper defined in > dmaengine.h. Add one for ->device_prep_dma_memcpy(). Looks good to me. Acked-by: Vinod Koul -- ~Vinod
Re: [PATCH 7/9] md: use kvmalloc rather than opencoded variant
On 01/30/2017 10:49 AM, Michal Hocko wrote:
From: Michal Hocko
copy_params uses kmalloc with vmalloc fallback. We already have a helper
for that - kvmalloc. This caller requires GFP_NOIO semantic so it hasn't
been converted with many others by previous patches. All we need to
achieve this semantic is to use the scope memalloc_noio_{save,restore}
around kvmalloc.
Cc: Mikulas Patocka
Cc: Mike Snitzer
Signed-off-by: Michal Hocko
Acked-by: Vlastimil Babka
---
drivers/md/dm-ioctl.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index a5a9b17f0f7f..dbf5b981f7d7 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1698,6 +1698,7 @@ static int copy_params(struct dm_ioctl __user *user,
struct dm_ioctl *param_kern
struct dm_ioctl *dmi;
int secure_data;
const size_t minimum_data_size = offsetof(struct dm_ioctl, data);
+ unsigned noio_flag;
if (copy_from_user(param_kernel, user, minimum_data_size))
return -EFAULT;
@@ -1720,15 +1721,9 @@ static int copy_params(struct dm_ioctl __user *user,
struct dm_ioctl *param_kern
* Use kmalloc() rather than vmalloc() when we can.
*/
dmi = NULL;
- if (param_kernel->data_size <= KMALLOC_MAX_SIZE)
- dmi = kmalloc(param_kernel->data_size, GFP_NOIO | __GFP_NORETRY
| __GFP_NOMEMALLOC | __GFP_NOWARN);
-
- if (!dmi) {
- unsigned noio_flag;
- noio_flag = memalloc_noio_save();
- dmi = __vmalloc(param_kernel->data_size, GFP_NOIO | __GFP_HIGH
| __GFP_HIGHMEM, PAGE_KERNEL);
- memalloc_noio_restore(noio_flag);
- }
+ noio_flag = memalloc_noio_save();
+ dmi = kvmalloc(param_kernel->data_size, GFP_KERNEL);
+ memalloc_noio_restore(noio_flag);
if (!dmi) {
if (secure_data && clear_user(user, param_kernel->data_size))
[PATCH] perf: fix topology test on systems with sparse CPUs
Topology test fails on systems with sparse CPUs, e.g.
CPU not present or offline:
36: Test topology in session :
--- start ---
test child forked, pid 23703
templ file: /tmp/perf-test-i2rNki
failed to write feature 13
perf: Segmentation fault
available: 2 nodes (0-1)
node 0 cpus: 0 6 8 10 16 22 24 26
node 0 size: 11797 MB
node 0 free: 10526 MB
node 1 cpus: 1 7 9 11 17 23 25 27
node 1 size: 12065 MB
node 1 free: 10770 MB
node distances:
node 0 1
0: 10 20
1: 20 10
Enumerating CPU ids from 0 to _SC_NPROCESSORS_CONF-1 in header.env.cpu[]
doesn't work on system like one above, because some ids are higher than
number of CPUs, and there can be gaps.
On top of that, if CPU is offline, we can't get topology info from
sysfs entries, because they don't exist for offline CPUs.
This patch stores topology data only for online CPUs in header.env.cpu[]
list, regardless of their CPU ids, and then uses cpu_map to translate
index to actual CPU id.
Example:
coreid socketid for CPU0
coreid socketid for CPU1
coreid socketid for CPU6
coreid socketid for CPU7
...
Alternative is we go from 0 to highest CPU id, but CPUs which are
missing would contain some dummy values in topology data.
Example:
coreid socketid for CPU0
coreid socketid for CPU1
-1 -1
-1 -1
-1 -1
-1 -1
coreid socketid for CPU6
coreid socketid for CPU7
...
Signed-off-by: Jan Stancek
---
tools/perf/tests/topology.c | 7 ---
tools/perf/util/env.c | 40
tools/perf/util/header.c| 36
3 files changed, 52 insertions(+), 31 deletions(-)
diff --git a/tools/perf/tests/topology.c b/tools/perf/tests/topology.c
index 98fe69ac553c..7b0b621ea8c0 100644
--- a/tools/perf/tests/topology.c
+++ b/tools/perf/tests/topology.c
@@ -66,17 +66,18 @@ static int check_cpu_topology(char *path, struct cpu_map
*map)
TEST_ASSERT_VAL("can't get session", session);
for (i = 0; i < session->header.env.nr_cpus_online; i++) {
- pr_debug("CPU %d, core %d, socket %d\n", i,
+ pr_debug("CPU %d, core %d, socket %d\n", map->map[i],
session->header.env.cpu[i].core_id,
session->header.env.cpu[i].socket_id);
}
for (i = 0; i < map->nr; i++) {
+ int cpu = map->map[i];
TEST_ASSERT_VAL("Core ID doesn't match",
- (session->header.env.cpu[map->map[i]].core_id ==
(cpu_map__get_core(map, i, NULL) & 0x)));
+ (session->header.env.cpu[i].core_id ==
(cpu_map__get_core_id(cpu) & 0x)));
TEST_ASSERT_VAL("Socket ID doesn't match",
- (session->header.env.cpu[map->map[i]].socket_id ==
cpu_map__get_socket(map, i, NULL)));
+ (session->header.env.cpu[i].socket_id ==
cpu_map__get_socket_id(cpu)));
}
perf_session__delete(session);
diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c
index bb964e86b09d..0c2cae807a61 100644
--- a/tools/perf/util/env.c
+++ b/tools/perf/util/env.c
@@ -60,29 +60,45 @@ int perf_env__set_cmdline(struct perf_env *env, int argc,
const char *argv[])
int perf_env__read_cpu_topology_map(struct perf_env *env)
{
- int cpu, nr_cpus;
+ int cpu, nr_cpus, i, err = 0;
+ struct cpu_map *map;
if (env->cpu != NULL)
return 0;
- if (env->nr_cpus_avail == 0)
- env->nr_cpus_avail = sysconf(_SC_NPROCESSORS_CONF);
+ map = cpu_map__new(NULL);
+ if (map == NULL) {
+ pr_debug("failed to get system cpumap\n");
+ err = -ENOMEM;
+ goto out;
+ }
+
+ if (env->nr_cpus_online == 0)
+ env->nr_cpus_online = map->nr;
- nr_cpus = env->nr_cpus_avail;
- if (nr_cpus == -1)
- return -EINVAL;
+ nr_cpus = env->nr_cpus_online;
+ if (nr_cpus == -1 || map->nr < nr_cpus) {
+ err = -EINVAL;
+ goto out_free;
+ }
env->cpu = calloc(nr_cpus, sizeof(env->cpu[0]));
- if (env->cpu == NULL)
- return -ENOMEM;
+ if (env->cpu == NULL) {
+ err = -ENOMEM;
+ goto out_free;
+ }
- for (cpu = 0; cpu < nr_cpus; ++cpu) {
- env->cpu[cpu].core_id = cpu_map__get_core_id(cpu);
- env->cpu[cpu].socket_id = cpu_map__get_socket_id(cpu);
+ for (i = 0; i < nr_cpus; i++) {
+ cpu = map->map[i];
+ env->cpu[i].core_id = cpu_map__get_core_id(cpu);
+ env->cpu[i].socket_id = cpu_map__get_socket_id(cpu);
}
env->nr_cpus_avail = nr_cpus;
- return 0;
+out_free:
+ cpu_map__put(map);
+out:
+ return err;
}
void cpu_cache_level__free(struct cpu_cache_level *cache)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index d89c9c7ef4e5..25
[PATCH] Documentation/sphinx: make targets independent of Sphinx work for HAVE_SPHINX=0
Make targets that don't depend on Sphinx work without warnings about missing Sphinx. 'make cleandocs' will work without Sphinx just fine, and the targets that are no-ops for Sphinx should just be skipped. Move them outside of the HAVE_SPHINX checks to take precedence over the .DEFAULT target for HAVE_SPHINX=0. Reported-by: Jim Davis Reference: http://lkml.kernel.org/r/ca+r1zhjrvqkjpxgogb_boax2hkfb+qqcttzffbmfeh1mfee...@mail.gmail.com Signed-off-by: Jani Nikula --- Documentation/Makefile.sphinx | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx index 707c65337ebf..d1aa7ffdea64 100644 --- a/Documentation/Makefile.sphinx +++ b/Documentation/Makefile.sphinx @@ -90,6 +90,11 @@ epubdocs: xmldocs: @$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,xml,$(var),xml,$(var))) +endif # HAVE_SPHINX + +# The following targets are independent of HAVE_SPHINX, and the rules should +# work or silently pass without Sphinx. + # no-ops for the Sphinx toolchain sgmldocs: psdocs: @@ -100,8 +105,6 @@ cleandocs: $(Q)rm -rf $(BUILDDIR) $(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) -C Documentation/media clean -endif # HAVE_SPHINX - dochelp: @echo ' Linux kernel internal documentation in different formats (Sphinx):' @echo ' htmldocs- HTML' -- 2.1.4
Re: scsi: use-after-free in sg_start_req
On Mon, Jan 30, 2017 at 5:36 PM, Bart Van Assche wrote: > On Mon, 2017-01-30 at 08:25 +0100, Dmitry Vyukov wrote: >> On commit ca63ff9b11f958efafd8c8fa60fda14baec6149c > > What kernel have you been testing? That commit is not in any upstream kernel. This is mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git auto-latest ca63ff9b11f958efafd8c8fa60fda14baec6149c commit ca63ff9b11f958efafd8c8fa60fda14baec6149c Date: Wed Jan 25 18:36:03 2017 +0800 mm/migration: make isolate_movable_page always defined
Re: [PATCH] perf/x86/intel/rapl: Rename rapl_cpu_prepare() to rapl_cpu_starting()
On Mon, 30 Jan 2017, Yasuaki Ishimatsu wrote: > Hi Thomas, > > Do you have any idea to fix the issue? > If you have the idea, please send me the patch. Yes, I have a patch, but need to do some tests and get changelogs written. Will keep you updated. Thanks, tglx
Re: [PATCH v6 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family
On Fri, Jan 27, 2017 at 10:40:09AM +0800, Baoyou Xie wrote: > On 27 January 2017 at 00:17, Mathieu Poirier > wrote: > > > On Thu, Jan 26, 2017 at 09:32:56AM +0800, Baoyou Xie wrote: > > > On 26 January 2017 at 00:23, Mathieu Poirier > > > > > wrote: > > > > > > > On Wed, Jan 25, 2017 at 10:44:49AM +0800, Baoyou Xie wrote: > > > > > This patch adds watchdog controller driver for ZTE's zx2967 family. > > > > > > > > > > Signed-off-by: Baoyou Xie > > > > > --- [ ... ] > > > > > + reset_control_assert(rstc); > > > > > + usleep_range(500, 2); > > > > > > > > Alright, I'm officially confused. > > > > > > > > First and foremost you still haven't provided an explanation as to why > > > > this is > > > > required. Second, in your previous submission you had: > > > > > > > > mdelay(10); > > > > > > > > That is a busy loop of 10ms. In this post using usleep_range() is a > > step > > > > in the > > > > right direction but the min and max values to wait for don't make > > sense. > > > > Here > > > > you have 500 and 2, which is 0.5ms and 20ms. > > > > > > > > In fact, sleeping for 0.5ms is enough. > > > we extended the sleeping time to 20ms, the purpose is merging the timer > > > interrupts. of course, it's happy to replace it with usleep_range(500, > > > 1000). > > > > "merging the timer interrupts" - you mean trying to get the WD tick to be > > closer > > to other timers? If so I really don't see why. Timers are asynchronous by > > nature and there can be dozens of them enabled at any given time. > > > > Really? > Even if the system runs asynchronously, early process may trigger delayed > process, for example delayed work queue or timers, we can merge our > watchdog timer and those delayed work's timers. > In the probe function ? > Furthermore, what happen if we build this driver as module? > If every driver writer would use that line of argument, booting would take much longer than necessary, with every process sitting on unnecessary wait or sleep calls for perceived "optimization" purposes. Probe functions run exactly once, and should be time optimized. You should have an idea what the minimum reset hold time is, and follow it. > But, as i said early, it's a trial optimization but can be instead with > usleep_range(500, 1000). > > In some case, such optimization is helpful. I'd like to talk a story here, > about before ten years, I pressed a return key in console, you know, in > this case, a process be created and exited, so the cpu core that process > run at sent an IPI to other CPU, IPI interrupt resulted in the performance > decreased by 20%, so sad:) > It appears to be somewhat unlikely that each keypress resulted in a driver being instantiated. If it did, a sleep in its probe function was the least of your problems. > Unless there is a H/W constraint requiring a delay between the > > assert/deassert > > of the WD, I don't think adding a wait operation (of any kind) make sense. Correct. Guenter
Re: [PATCH] printk: fix printk.devkmsg sysctl
On Mon, Jan 30, 2017 at 02:38:03PM +0100, Petr Mladek wrote: > We must not access userspace pointer directly. One solution would be > to use get_user(). Good point. > But a better solution might be to check also the trailing '\0' in > __control_devkmsg, see below. I has several advantages: > >+ we will never assign "invalid" value to @devkmsg_log and > do not need to revert it. Only devkmsg_log_str must be > reverted. > >+ __control_devkmsg() do not need to return the length of the > string. We could simply check the error code. > >* the err variable will have the same meaning for both > __control_devkmsg() and proc_dostring(). > Sounds good to me. > Note that > >echo "ratelimitXX" >/proc/sys/kernel/printk_devkmsg > > succeeds because the copied string is limited by DEVKMSG_STR_MAX_SIZE. > We would need to add at least one byte to be able to detect an error > but I am not sure if it is worth it. So my reasoning here was to allow only '' or '\n' - where is one of the three accepted settings and fail everything else. That's why I did return the strlen. Accepting $ echo "ratelimitXX" > ... looks strange to me and silly and misleading and... IOW, I'd like the user to know what she does and mean it. No sloppy inputs. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: linux-next: manual merge of the gpio tree with the staging tree
On Mon, Jan 30, 2017 at 03:28:55PM +1100, Stephen Rothwell wrote:
> Hi Linus,
>
> Today's linux-next merge of the gpio tree got a conflict in:
>
> drivers/staging/greybus/gpio.c
>
> between commit:
>
> 1d3dfbd1dd34 ("staging: greybus: fix checkpatch unsigned warnings")
>
> from the staging tree and commit:
>
> 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO
> chips")
>
> from the gpio 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 drivers/staging/greybus/gpio.c
> index 558550cfe687,51384bdde450..
> --- a/drivers/staging/greybus/gpio.c
> +++ b/drivers/staging/greybus/gpio.c
> @@@ -474,17 -474,20 +474,20 @@@ static void gb_gpio_set(struct gpio_chi
> gb_gpio_set_value_operation(ggc, (u8)offset, !!value);
> }
>
> - static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
> - unsigned int debounce)
> -static int gb_gpio_set_config(struct gpio_chip *chip, unsigned offset,
> ++static int gb_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
> + unsigned long config)
> {
> struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
> - u16 usec;
> + u32 debounce;
>
> + if (pinconf_to_config_param(config) != PIN_CONFIG_INPUT_DEBOUNCE)
> + return -ENOTSUPP;
> +
> + debounce = pinconf_to_config_argument(config);
> if (debounce > U16_MAX)
> return -EINVAL;
> - usec = (u16)debounce;
>
> - return gb_gpio_set_debounce_operation(ggc, (u8)offset, usec);
> + return gb_gpio_set_debounce_operation(ggc, (u8)offset, (u16)debounce);
> }
>
> static int gb_gpio_controller_setup(struct gb_gpio_controller *ggc)
Looks good, thanks for this.
greg k-h
Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM
On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote: > >> 2. It tickles a latent bug during resume where the timer triggers >> before we re-connect. The trouble is that we now try to dereference >> queue->rx.sring which is NULL since we disconnect in >> netfront_resume(). (Curiously, I only observe it with 32-bit guests) > I think we may hit this bug after removing the timer as well. We call > RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference > queue->rx.sring. If the timer is deleted in xennet_disconnect_backend() then why would anyone be pushing anything to the backend after that? -boris
Re: [RFC v2 10/10] KVM: arm/arm64: Emulate the EL1 phys timer register access
Hi Marc,
On Sun, Jan 29, 2017 at 10:44 AM, Marc Zyngier wrote:
> On Fri, Jan 27 2017 at 01:05:00 AM, Jintack Lim
> wrote:
>> Emulate read and write operations to CNTP_TVAL, CNTP_CVAL and CNTP_CTL.
>> Now VMs are able to use the EL1 physical timer.
>>
>> Signed-off-by: Jintack Lim
>> ---
>> arch/arm64/kvm/sys_regs.c| 32 +---
>> include/kvm/arm_arch_timer.h | 2 ++
>> virt/kvm/arm/arch_timer.c| 2 +-
>> 3 files changed, 32 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> index fd9e747..adf009f 100644
>> --- a/arch/arm64/kvm/sys_regs.c
>> +++ b/arch/arm64/kvm/sys_regs.c
>> @@ -824,7 +824,14 @@ static bool access_cntp_tval(struct kvm_vcpu *vcpu,
>> struct sys_reg_params *p,
>> const struct sys_reg_desc *r)
>> {
>> - kvm_inject_undefined(vcpu);
>> + struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
>> + u64 now = kvm_phys_timer_read();
>> +
>> + if (p->is_write)
>> + ptimer->cnt_cval = p->regval + now;
>> + else
>> + p->regval = ptimer->cnt_cval - now;
>> +
>> return true;
>> }
>>
>> @@ -832,7 +839,20 @@ static bool access_cntp_ctl(struct kvm_vcpu *vcpu,
>> struct sys_reg_params *p,
>> const struct sys_reg_desc *r)
>> {
>> - kvm_inject_undefined(vcpu);
>> + struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
>> +
>> + if (p->is_write) {
>> + /* ISTATUS bit is read-only */
>> + ptimer->cnt_ctl = p->regval & ~ARCH_TIMER_CTRL_IT_STAT;
>> + } else {
>> + u64 now = kvm_phys_timer_read();
>> +
>> + p->regval = ptimer->cnt_ctl;
>> + /* Set ISTATUS bit if it's expired */
>> + if (ptimer->cnt_cval <= now)
>> + p->regval |= ARCH_TIMER_CTRL_IT_STAT;
>> + }
>
> Shouldn't we take the ENABLE bit into account? The ARMv8 ARM version I
> have at hand (version h) seems to indicate that we should, but we should
> check with the latest and greatest...
Thanks! I was not clear about this. I have ARM ARM version k, and it
says that 'When the value of the ENABLE bit is 0, the ISTATUS field is
UNKNOWN.' So I thought the istatus value doesn't matter if ENABLE is
0, and just set istatus bit regardless of ENABLE bit. If this is not
what the manual meant, then I'm happy to fix this.
Thanks,
Jintack
>
>> +
>> return true;
>> }
>>
>> @@ -840,7 +860,13 @@ static bool access_cntp_cval(struct kvm_vcpu *vcpu,
>> struct sys_reg_params *p,
>> const struct sys_reg_desc *r)
>> {
>> - kvm_inject_undefined(vcpu);
>> + struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
>> +
>> + if (p->is_write)
>> + ptimer->cnt_cval = p->regval;
>> + else
>> + p->regval = ptimer->cnt_cval;
>> +
>> return true;
>> }
>>
>> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
>> index a364593..fec99f2 100644
>> --- a/include/kvm/arm_arch_timer.h
>> +++ b/include/kvm/arm_arch_timer.h
>> @@ -74,6 +74,8 @@ bool kvm_timer_should_fire(struct kvm_vcpu *vcpu,
>> void kvm_timer_schedule(struct kvm_vcpu *vcpu);
>> void kvm_timer_unschedule(struct kvm_vcpu *vcpu);
>>
>> +u64 kvm_phys_timer_read(void);
>> +
>> void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
>>
>> void kvm_timer_init_vhe(void);
>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>> index b366bb2..9eec063 100644
>> --- a/virt/kvm/arm/arch_timer.c
>> +++ b/virt/kvm/arm/arch_timer.c
>> @@ -40,7 +40,7 @@ void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu)
>> vcpu_vtimer(vcpu)->active_cleared_last = false;
>> }
>>
>> -static u64 kvm_phys_timer_read(void)
>> +u64 kvm_phys_timer_read(void)
>> {
>> return timecounter->cc->read(timecounter->cc);
>> }
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny.
>
Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
On Sat, 28 Jan 2017, Peter Senna Tschudin wrote:
> On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote:
> Hi Archit,
>
> Thank you for the comments!
>
> [...]
>> > + total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
>> > + if (total_size > EDID_LENGTH) {
>> > + kfree(block);
>> > + block = kmalloc(total_size, GFP_KERNEL);
>> > + if (!block)
>> > + return NULL;
>> > +
>> > + /* Yes, read the entire buffer, and do not skip the first
>> > + * EDID_LENGTH bytes.
>> > + */
>>
>> Is this the reason why you aren't using drm_do_get_edid()?
>
> Yes, for some hw specific reason, it is necessary to read the entire
> EDID buffer starting from 0, not block by block.
Hrmh, I'm planning on moving the edid override and firmware edid
mechanisms at the drm_do_get_edid() level to be able to truly and
transparently use a different edid. Currently, they're only used for
modes, really, and lead to some info retrieved from overrides, some from
the real edid. This kind of hacks will bypass the override/firmware edid
mechanisms then too. :(
BR,
Jani.
>
> [...]
>
> I fixed all your other suggestions. Thank you!
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
Re: [PATCH] Staging: media: lirc: style fix, using octal file permissions
On Sat, Jan 07, 2017 at 04:02:55PM +1300, Derek Robson wrote:
> Change file permissions to octal style.
> Found using checkpatch
>
> Signed-off-by: Derek Robson
> ---
> drivers/staging/media/lirc/lirc_imon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/lirc/lirc_imon.c
> b/drivers/staging/media/lirc/lirc_imon.c
> index 1e650fba4a92..6c8a4a15278e 100644
> --- a/drivers/staging/media/lirc/lirc_imon.c
> +++ b/drivers/staging/media/lirc/lirc_imon.c
> @@ -182,7 +182,7 @@ MODULE_DESCRIPTION(MOD_DESC);
> MODULE_VERSION(MOD_VERSION);
> MODULE_LICENSE("GPL");
> MODULE_DEVICE_TABLE(usb, imon_usb_id_table);
> -module_param(debug, int, S_IRUGO | S_IWUSR);
> +module_param(debug, int, 0644);
> MODULE_PARM_DESC(debug, "Debug messages: 0=no, 1=yes(default: no)");
>
> static void free_imon_context(struct imon_context *context)
In the current media tree, drivers/staging/media/lirc/lirc_imon.c has
been merged with drivers/media/rc/imon.c already, I'm afraid. This
patch no longer applies.
Sean
[PATCH 2/5] gpio: 104-idi-48: Add support for GPIO names
This patch sets the gpio_chip names option with an array of GPIO line
names that match the manual documentation for the ACCES 104-IDI-48.
This should make it easier for users to identify which GPIO line
corresponds to a respective GPIO pin on the device.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-104-idi-48.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-104-idi-48.c b/drivers/gpio/gpio-104-idi-48.c
index eafbf053f3e8..db8bf23e47b8 100644
--- a/drivers/gpio/gpio-104-idi-48.c
+++ b/drivers/gpio/gpio-104-idi-48.c
@@ -217,6 +217,18 @@ static irqreturn_t idi_48_irq_handler(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+#define IDI48_NGPIO 48
+static const char *idi48_names[IDI48_NGPIO] = {
+ "Bit 0 A", "Bit 1 A", "Bit 2 A", "Bit 3 A", "Bit 4 A", "Bit 5 A",
+ "Bit 6 A", "Bit 7 A", "Bit 8 A", "Bit 9 A", "Bit 10 A", "Bit 11 A",
+ "Bit 12 A", "Bit 13 A", "Bit 14 A", "Bit 15 A", "Bit 16 A", "Bit 17 A",
+ "Bit 18 A", "Bit 19 A", "Bit 20 A", "Bit 21 A", "Bit 22 A", "Bit 23 A",
+ "Bit 0 B", "Bit 1 B", "Bit 2 B", "Bit 3 B", "Bit 4 B", "Bit 5 B",
+ "Bit 6 B", "Bit 7 B", "Bit 8 B", "Bit 9 B", "Bit 10 B", "Bit 11 B",
+ "Bit 12 B", "Bit 13 B", "Bit 14 B", "Bit 15 B", "Bit 16 B", "Bit 17 B",
+ "Bit 18 B", "Bit 19 B", "Bit 20 B", "Bit 21 B", "Bit 22 B", "Bit 23 B"
+};
+
static int idi_48_probe(struct device *dev, unsigned int id)
{
struct idi_48_gpio *idi48gpio;
@@ -237,7 +249,8 @@ static int idi_48_probe(struct device *dev, unsigned int id)
idi48gpio->chip.parent = dev;
idi48gpio->chip.owner = THIS_MODULE;
idi48gpio->chip.base = -1;
- idi48gpio->chip.ngpio = 48;
+ idi48gpio->chip.ngpio = IDI48_NGPIO;
+ idi48gpio->chip.names = idi48_names;
idi48gpio->chip.get_direction = idi_48_gpio_get_direction;
idi48gpio->chip.direction_input = idi_48_gpio_direction_input;
idi48gpio->chip.get = idi_48_gpio_get;
--
2.11.0
[PATCH 0/5] gpio: Add support for GPIO names for several ISA_BUS_API drivers
This patchset sets the gpio_chip names option of several ISA_BUS_API GPIO drivers with an array of GPIO line names that match their respective manual documentation. This should make it easier for users to identify which GPIO line corresponds to a respective GPIO pin on their device. William Breathitt Gray (5): gpio: 104-dio-48e: Add support for GPIO names gpio: 104-idi-48: Add support for GPIO names gpio: 104-idio-16: Add support for GPIO names gpio: gpio-mm: Add support for GPIO names gpio: ws16c48: Add support for GPIO names drivers/gpio/gpio-104-dio-48e.c | 23 ++- drivers/gpio/gpio-104-idi-48.c | 15 ++- drivers/gpio/gpio-104-idio-16.c | 11 ++- drivers/gpio/gpio-gpio-mm.c | 15 ++- drivers/gpio/gpio-ws16c48.c | 19 ++- 5 files changed, 78 insertions(+), 5 deletions(-) -- 2.11.0
Re: [PATCH] Documentation/sphinx: make targets independent of Sphinx work for HAVE_SPHINX=0
On Mon, 30 Jan 2017, Jani Nikula wrote: > Make targets that don't depend on Sphinx work without warnings about > missing Sphinx. 'make cleandocs' will work without Sphinx just fine, and > the targets that are no-ops for Sphinx should just be skipped. Move them > outside of the HAVE_SPHINX checks to take precedence over the .DEFAULT > target for HAVE_SPHINX=0. > > Reported-by: Jim Davis > Reference: > http://lkml.kernel.org/r/ca+r1zhjrvqkjpxgogb_boax2hkfb+qqcttzffbmfeh1mfee...@mail.gmail.com Cc: sta...@vger.kernel.org Might not be unreasonable. > Signed-off-by: Jani Nikula > --- > Documentation/Makefile.sphinx | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx > index 707c65337ebf..d1aa7ffdea64 100644 > --- a/Documentation/Makefile.sphinx > +++ b/Documentation/Makefile.sphinx > @@ -90,6 +90,11 @@ epubdocs: > xmldocs: > @$(foreach var,$(SPHINXDIRS),$(call > loop_cmd,sphinx,xml,$(var),xml,$(var))) > > +endif # HAVE_SPHINX > + > +# The following targets are independent of HAVE_SPHINX, and the rules should > +# work or silently pass without Sphinx. > + > # no-ops for the Sphinx toolchain > sgmldocs: > psdocs: > @@ -100,8 +105,6 @@ cleandocs: > $(Q)rm -rf $(BUILDDIR) > $(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) -C Documentation/media clean > > -endif # HAVE_SPHINX > - > dochelp: > @echo ' Linux kernel internal documentation in different formats > (Sphinx):' > @echo ' htmldocs- HTML' -- Jani Nikula, Intel Open Source Technology Center
Re: [PATCH 0/6 v3] kvmalloc
On 01/30/2017 08:56 AM, Michal Hocko wrote: On Fri 27-01-17 21:12:26, Daniel Borkmann wrote: On 01/27/2017 11:05 AM, Michal Hocko wrote: On Thu 26-01-17 21:34:04, Daniel Borkmann wrote: [...] So to answer your second email with the bpf and netfilter hunks, why not replacing them with kvmalloc() and __GFP_NORETRY flag and add that big fat FIXME comment above there, saying explicitly that __GFP_NORETRY is not harmful though has only /partial/ effect right now and that full support needs to be implemented in future. That would still be better that not having it, imo, and the FIXME would make expectations clear to anyone reading that code. Well, we can do that, I just would like to prevent from this (ab)use if there is no _real_ and _sensible_ usecase for it. Having a real bug Understandable. report or a fallback mechanism you are mentioning above would justify the (ab)use IMHO. But that abuse would be documented properly and have a real reason to exist. That sounds like a better approach to me. But if you absolutely _insist_ I can change that. Yeah, please do (with a big FIXME comment as mentioned), this originally came from a real bug report. Anyway, feel free to add my Acked-by then. Thanks! I will repost the whole series today. Looks like I got only Cc'ed on the cover letter of your v3 from today (should have been v4 actually?). Anyway, I looked up the last patch on lkml [1] and it seems you forgot the __GFP_NORETRY we talked about? At least that was what was discussed above (insisting on __GFP_NORETRY plus FIXME comment) for providing my Acked-by then. Can you still fix that up in a final respin? Thanks again, Daniel [1] https://lkml.org/lkml/2017/1/30/129
Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced
On 01/24/2017 08:05 AM, zhichang.yuan wrote:
Low-pin-count interface is integrated into some SoCs. The accesses to those
peripherals under LPC make use of I/O ports rather than the memory mapped I/O.
To drive these devices, this patch introduces a method named indirect-IO.
In this method the in/out() accessor in include/asm-generic/io.h will be
redefined. When upper layer drivers call in/out() with those known legacy port
addresses to access the peripherals, the I/O operations will be routed to the
right hooks which are registered specific to the host device, such as LPC.
Then the hardware relevant manupulations are finished by the corresponding
host.
According to the comments on V5, this patch adds a common indirect-IO driver
which support this I/O indirection to the generic directory.
In the later pathches, some host-relevant drivers are implemented to support
the specific I/O hooks and register them.
Based on these, the upper layer drivers which depend on in/out() can work well
without any extra work or any changes.
Signed-off-by: zhichang.yuan
Signed-off-by: Gabriele Paoloni
Signed-off-by: John Garry
I like the extio idea. That allows us to handle all PIO requests on
platforms that don't have native PIO support via different routes
depending on the region they're in. Unfortunately we now we have 2
frameworks for handling sparse PIO regions: One in extio, one in PCI.
Why don't we just merge the two? Most of the code that has #ifdef
PCI_IOBASE throughout the code base sounds like an ideal candidate to
get migrated to extio instead. Then we only have a single framework to
worry about ...
---
include/asm-generic/io.h | 50
include/linux/extio.h| 85 +++
include/linux/io.h | 1 +
lib/Kconfig | 8 +++
lib/Makefile | 2 +
lib/extio.c | 147 +++
6 files changed, 293 insertions(+)
create mode 100644 include/linux/extio.h
create mode 100644 lib/extio.c
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 7ef015e..c0d6db1 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -21,6 +21,8 @@
#include
+#include
+
#ifndef mmiowb
#define mmiowb() do {} while (0)
#endif
@@ -358,51 +360,75 @@ static inline void writesq(volatile void __iomem *addr,
const void *buffer,
*/
#ifndef inb
+#ifdef CONFIG_INDIRECT_PIO
+#define inb extio_inb
+#else
#define inb inb
static inline u8 inb(unsigned long addr)
{
return readb(PCI_IOBASE + addr);
}
+#endif /* CONFIG_INDIRECT_PIO */
... we would also get rid of all of these constructs. Instead, every
architecture that doesn't implement native PIO defines would end up in
extio and we would enable it unconditionally for them.
#endif
#ifndef inw
+#ifdef CONFIG_INDIRECT_PIO
+#define inw extio_inw
+#else
#define inw inw
static inline u16 inw(unsigned long addr)
{
return readw(PCI_IOBASE + addr);
}
+#endif /* CONFIG_INDIRECT_PIO */
#endif
#ifndef inl
+#ifdef CONFIG_INDIRECT_PIO
+#define inl extio_inl
+#else
#define inl inl
static inline u32 inl(unsigned long addr)
{
return readl(PCI_IOBASE + addr);
}
+#endif /* CONFIG_INDIRECT_PIO */
#endif
#ifndef outb
+#ifdef CONFIG_INDIRECT_PIO
+#define outb extio_outb
+#else
#define outb outb
static inline void outb(u8 value, unsigned long addr)
{
writeb(value, PCI_IOBASE + addr);
}
+#endif /* CONFIG_INDIRECT_PIO */
#endif
#ifndef outw
+#ifdef CONFIG_INDIRECT_PIO
+#define outw extio_outw
+#else
#define outw outw
static inline void outw(u16 value, unsigned long addr)
{
writew(value, PCI_IOBASE + addr);
}
+#endif /* CONFIG_INDIRECT_PIO */
#endif
#ifndef outl
+#ifdef CONFIG_INDIRECT_PIO
+#define outl extio_outl
+#else
#define outl outl
static inline void outl(u32 value, unsigned long addr)
{
writel(value, PCI_IOBASE + addr);
}
+#endif /* CONFIG_INDIRECT_PIO */
#endif
#ifndef inb_p
@@ -459,54 +485,78 @@ static inline void outl_p(u32 value, unsigned long addr)
*/
#ifndef insb
+#ifdef CONFIG_INDIRECT_PIO
+#define insb extio_insb
+#else
#define insb insb
static inline void insb(unsigned long addr, void *buffer, unsigned int count)
{
readsb(PCI_IOBASE + addr, buffer, count);
}
+#endif /* CONFIG_INDIRECT_PIO */
#endif
#ifndef insw
+#ifdef CONFIG_INDIRECT_PIO
+#define insw extio_insw
+#else
#define insw insw
static inline void insw(unsigned long addr, void *buffer, unsigned int count)
{
readsw(PCI_IOBASE + addr, buffer, count);
}
+#endif /* CONFIG_INDIRECT_PIO */
#endif
#ifndef insl
+#ifdef CONFIG_INDIRECT_PIO
+#define insl extio_insl
+#else
#define insl insl
static inline void insl(unsigned long addr, void *buffer, unsigned int count)
{
readsl(PCI_IOBASE + addr, buffer, count);
}
+#endif /* CONFIG_INDIRECT_PIO *
Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM
On 01/30/2017 09:06 AM, Boris Ostrovsky wrote: On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote: 2. It tickles a latent bug during resume where the timer triggers before we re-connect. The trouble is that we now try to dereference queue->rx.sring which is NULL since we disconnect in netfront_resume(). (Curiously, I only observe it with 32-bit guests) I think we may hit this bug after removing the timer as well. We call RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference queue->rx.sring. If the timer is deleted in xennet_disconnect_backend() then why would anyone be pushing anything to the backend after that? Sorry, I got the ordering wrong. Thanks for the clarification.. Thanks, Vineeth
Re: [PATCH 0/6 v3] kvmalloc
On 01/30/2017 05:28 PM, Michal Hocko wrote: On Mon 30-01-17 17:15:08, Daniel Borkmann wrote: On 01/30/2017 08:56 AM, Michal Hocko wrote: On Fri 27-01-17 21:12:26, Daniel Borkmann wrote: On 01/27/2017 11:05 AM, Michal Hocko wrote: On Thu 26-01-17 21:34:04, Daniel Borkmann wrote: [...] So to answer your second email with the bpf and netfilter hunks, why not replacing them with kvmalloc() and __GFP_NORETRY flag and add that big fat FIXME comment above there, saying explicitly that __GFP_NORETRY is not harmful though has only /partial/ effect right now and that full support needs to be implemented in future. That would still be better that not having it, imo, and the FIXME would make expectations clear to anyone reading that code. Well, we can do that, I just would like to prevent from this (ab)use if there is no _real_ and _sensible_ usecase for it. Having a real bug Understandable. report or a fallback mechanism you are mentioning above would justify the (ab)use IMHO. But that abuse would be documented properly and have a real reason to exist. That sounds like a better approach to me. But if you absolutely _insist_ I can change that. Yeah, please do (with a big FIXME comment as mentioned), this originally came from a real bug report. Anyway, feel free to add my Acked-by then. Thanks! I will repost the whole series today. Looks like I got only Cc'ed on the cover letter of your v3 from today (should have been v4 actually?). Yes Anyway, I looked up the last patch on lkml [1] and it seems you forgot the __GFP_NORETRY we talked about? I misread your response. I thought you were OK with the FIXME explanation. At least that was what was discussed above (insisting on __GFP_NORETRY plus FIXME comment) for providing my Acked-by then. Can you still fix that up in a final respin? I will probably just drop that last patch instead. I am not convinced that we should bend the new API over and let people mimic that throughout the code. I have just seen too many examples of this pattern already. I would also like to prevent the next rebase, unless there any issues with some patches of course. Ok, I'm fine with that as well. Thanks, Daniel
[PATCH 1/5] gpio: 104-dio-48e: Add support for GPIO names
This patch sets the gpio_chip names option with an array of GPIO line
names that match the manual documentation for the ACCES 104-DIO-48E.
This should make it easier for users to identify which GPIO line
corresponds to a respective GPIO pin on the device.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-104-dio-48e.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-104-dio-48e.c b/drivers/gpio/gpio-104-dio-48e.c
index 221243f17d4e..84e529b4f5d8 100644
--- a/drivers/gpio/gpio-104-dio-48e.c
+++ b/drivers/gpio/gpio-104-dio-48e.c
@@ -338,6 +338,26 @@ static irqreturn_t dio48e_irq_handler(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+#define DIO48E_NGPIO 48
+static const char *dio48e_names[DIO48E_NGPIO] = {
+ "PPI Group 0 Port A 0", "PPI Group 0 Port A 1", "PPI Group 0 Port A 2",
+ "PPI Group 0 Port A 3", "PPI Group 0 Port A 4", "PPI Group 0 Port A 5",
+ "PPI Group 0 Port A 6", "PPI Group 0 Port A 7", "PPI Group 0 Port B 0",
+ "PPI Group 0 Port B 1", "PPI Group 0 Port B 2", "PPI Group 0 Port B 3",
+ "PPI Group 0 Port B 4", "PPI Group 0 Port B 5", "PPI Group 0 Port B 6",
+ "PPI Group 0 Port B 7", "PPI Group 0 Port C 0", "PPI Group 0 Port C 1",
+ "PPI Group 0 Port C 2", "PPI Group 0 Port C 3", "PPI Group 0 Port C 4",
+ "PPI Group 0 Port C 5", "PPI Group 0 Port C 6", "PPI Group 0 Port C 7",
+ "PPI Group 1 Port A 0", "PPI Group 1 Port A 1", "PPI Group 1 Port A 2",
+ "PPI Group 1 Port A 3", "PPI Group 1 Port A 4", "PPI Group 1 Port A 5",
+ "PPI Group 1 Port A 6", "PPI Group 1 Port A 7", "PPI Group 1 Port B 0",
+ "PPI Group 1 Port B 1", "PPI Group 1 Port B 2", "PPI Group 1 Port B 3",
+ "PPI Group 1 Port B 4", "PPI Group 1 Port B 5", "PPI Group 1 Port B 6",
+ "PPI Group 1 Port B 7", "PPI Group 1 Port C 0", "PPI Group 1 Port C 1",
+ "PPI Group 1 Port C 2", "PPI Group 1 Port C 3", "PPI Group 1 Port C 4",
+ "PPI Group 1 Port C 5", "PPI Group 1 Port C 6", "PPI Group 1 Port C 7"
+};
+
static int dio48e_probe(struct device *dev, unsigned int id)
{
struct dio48e_gpio *dio48egpio;
@@ -358,7 +378,8 @@ static int dio48e_probe(struct device *dev, unsigned int id)
dio48egpio->chip.parent = dev;
dio48egpio->chip.owner = THIS_MODULE;
dio48egpio->chip.base = -1;
- dio48egpio->chip.ngpio = 48;
+ dio48egpio->chip.ngpio = DIO48E_NGPIO;
+ dio48egpio->chip.names = dio48e_names;
dio48egpio->chip.get_direction = dio48e_gpio_get_direction;
dio48egpio->chip.direction_input = dio48e_gpio_direction_input;
dio48egpio->chip.direction_output = dio48e_gpio_direction_output;
--
2.11.0
[PATCH 5/5] gpio: ws16c48: Add support for GPIO names
This patch sets the gpio_chip names option with an array of GPIO line
names that match the manual documentation for the WinSystems WS16C48.
This should make it easier for users to identify which GPIO line
corresponds to a respective GPIO pin on the device.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-ws16c48.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-ws16c48.c b/drivers/gpio/gpio-ws16c48.c
index 65de20dfbe7a..a49377cf36fd 100644
--- a/drivers/gpio/gpio-ws16c48.c
+++ b/drivers/gpio/gpio-ws16c48.c
@@ -341,6 +341,22 @@ static irqreturn_t ws16c48_irq_handler(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+#define WS16C48_NGPIO 48
+static const char *ws14c48_names[WS16C48_NGPIO] = {
+ "Port 0 Bit 0", "Port 0 Bit 1", "Port 0 Bit 2", "Port 0 Bit 3",
+ "Port 0 Bit 4", "Port 0 Bit 5", "Port 0 Bit 6", "Port 0 Bit 7",
+ "Port 1 Bit 0", "Port 1 Bit 1", "Port 1 Bit 2", "Port 1 Bit 3",
+ "Port 1 Bit 4", "Port 1 Bit 5", "Port 1 Bit 6", "Port 1 Bit 7",
+ "Port 2 Bit 0", "Port 2 Bit 1", "Port 2 Bit 2", "Port 2 Bit 3",
+ "Port 2 Bit 4", "Port 2 Bit 5", "Port 2 Bit 6", "Port 2 Bit 7",
+ "Port 3 Bit 0", "Port 3 Bit 1", "Port 3 Bit 2", "Port 3 Bit 3",
+ "Port 3 Bit 4", "Port 3 Bit 5", "Port 3 Bit 6", "Port 3 Bit 7",
+ "Port 4 Bit 0", "Port 4 Bit 1", "Port 4 Bit 2", "Port 4 Bit 3",
+ "Port 4 Bit 4", "Port 4 Bit 5", "Port 4 Bit 6", "Port 4 Bit 7",
+ "Port 5 Bit 0", "Port 5 Bit 1", "Port 5 Bit 2", "Port 5 Bit 3",
+ "Port 5 Bit 4", "Port 5 Bit 5", "Port 5 Bit 6", "Port 5 Bit 7"
+};
+
static int ws16c48_probe(struct device *dev, unsigned int id)
{
struct ws16c48_gpio *ws16c48gpio;
@@ -361,7 +377,8 @@ static int ws16c48_probe(struct device *dev, unsigned int
id)
ws16c48gpio->chip.parent = dev;
ws16c48gpio->chip.owner = THIS_MODULE;
ws16c48gpio->chip.base = -1;
- ws16c48gpio->chip.ngpio = 48;
+ ws16c48gpio->chip.ngpio = WS16C48_NGPIO;
+ ws16c48gpio->chip.names = ws16c48_names;
ws16c48gpio->chip.get_direction = ws16c48_gpio_get_direction;
ws16c48gpio->chip.direction_input = ws16c48_gpio_direction_input;
ws16c48gpio->chip.direction_output = ws16c48_gpio_direction_output;
--
2.11.0
[PATCH 0/2] ARM: cache-uniphier: two cleanup patches
Sorry that I had not replied earlier. I came back to this finally. I guess we were seeing different code base the last time. This seems correct to me, so I'd like to put it in Russell's patch tracker. Masahiro Yamada (2): ARM: cache-uniphier: include instead of ARM: cache-uniphier: clean up active way setup code arch/arm/include/asm/hardware/cache-uniphier.h | 2 +- arch/arm/mm/cache-uniphier.c | 23 +-- 2 files changed, 10 insertions(+), 15 deletions(-) -- 2.7.4
[PATCH v3] iio: cros_ec_light_prox: add ChromeOS EC Light and Proximity Sensors
From: Gwendal Grignou
Handle Light and Proximity sensors presented by the ChromeOS EC Sensor hub.
Creates an IIO device for each functions.
Signed-off-by: Gwendal Grignou
Signed-off-by: Guenter Roeck
Signed-off-by: Enric Balletbo i Serra
---
Changes since v3:
- Move to iio/light directory.
- Revert a change made in v2. Use PROCESSED for light and RAW for proximity
as discussed.
- Removed BIT(IIO_CHAN_INFO_SCALE) (Jonathan: 'For the proximity it's normal
to provide raw with no known scale')
Changes since v2:
- Depends on IIO_CROS_EC_SENSORS_CORE instead of select
- Use PROCESSED for light and proximity, remove SCALE
drivers/iio/light/Kconfig | 10 ++
drivers/iio/light/Makefile | 1 +
drivers/iio/light/cros_ec_light_prox.c | 289 +
3 files changed, 300 insertions(+)
create mode 100644 drivers/iio/light/cros_ec_light_prox.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 298ea50..71c93b5e 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -126,6 +126,16 @@ config CM36651
To compile this driver as a module, choose M here:
the module will be called cm36651.
+config IIO_CROS_EC_LIGHT_PROX
+ tristate "ChromeOS EC Light and Proximity Sensors"
+ depends on IIO_CROS_EC_SENSORS_CORE
+ help
+ Say Y here if you use the light and proximity sensors
+ presented by the ChromeOS EC Sensor hub.
+
+ To compile this driver as a module, choose M here:
+ the module will be called cros_ec_light_prox.
+
config GP2AP020A00F
tristate "Sharp GP2AP020A00F Proximity/ALS sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 4de5200..844deeb 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_CM32181) += cm32181.o
obj-$(CONFIG_CM3232) += cm3232.o
obj-$(CONFIG_CM3323) += cm3323.o
obj-$(CONFIG_CM36651) += cm36651.o
+obj-$(CONFIG_IIO_CROS_EC_LIGHT_PROX) += cros_ec_light_prox.o
obj-$(CONFIG_GP2AP020A00F) += gp2ap020a00f.o
obj-$(CONFIG_HID_SENSOR_ALS) += hid-sensor-als.o
obj-$(CONFIG_HID_SENSOR_PROX) += hid-sensor-prox.o
diff --git a/drivers/iio/light/cros_ec_light_prox.c
b/drivers/iio/light/cros_ec_light_prox.c
new file mode 100644
index 000..7217223
--- /dev/null
+++ b/drivers/iio/light/cros_ec_light_prox.c
@@ -0,0 +1,289 @@
+/*
+ * cros_ec_light_prox - Driver for light and prox sensors behing CrosEC.
+ *
+ * Copyright (C) 2017 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../common/cros_ec_sensors/cros_ec_sensors_core.h"
+
+/*
+ * We only represent one entry for light or proximity. EC is merging different
+ * light sensors to return the what the eye would see. For proximity, we
+ * currently support only one light source.
+ */
+#define CROS_EC_LIGHT_PROX_MAX_CHANNELS (1 + 1)
+
+/* State data for ec_sensors iio driver. */
+struct cros_ec_light_prox_state {
+ /* Shared by all sensors */
+ struct cros_ec_sensors_core_state core;
+
+ struct iio_chan_spec channels[CROS_EC_LIGHT_PROX_MAX_CHANNELS];
+};
+
+static int cros_ec_light_prox_read(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct cros_ec_light_prox_state *st = iio_priv(indio_dev);
+ u16 data = 0;
+ s64 val64;
+ int ret = IIO_VAL_INT;
+ int idx = chan->scan_index;
+
+ mutex_lock(&st->core.cmd_lock);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ if (chan->type == IIO_PROXIMITY) {
+ if (cros_ec_sensors_read_cmd(indio_dev, 1 << idx,
+(s16 *)&data) < 0) {
+ ret = -EIO;
+ break;
+ }
+ *val = data;
+ } else {
+ ret = -EINVAL;
+ }
+ break;
+ case IIO_CHAN_INFO_PROCESSED:
+ if (chan->type == IIO_LIGHT) {
+ if (cros_ec_sensors_read_cmd(indio_dev, 1 << idx,
+(s16 *)&data) < 0) {
+
[PATCH 3/5] gpio: 104-idio-16: Add support for GPIO names
This patch sets the gpio_chip names option with an array of GPIO line
names that match the manual documentation for the ACCES 104-IDIO-16.
This should make it easier for users to identify which GPIO line
corresponds to a respective GPIO pin on the device.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-104-idio-16.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-104-idio-16.c b/drivers/gpio/gpio-104-idio-16.c
index 01a091e17614..96e740551976 100644
--- a/drivers/gpio/gpio-104-idio-16.c
+++ b/drivers/gpio/gpio-104-idio-16.c
@@ -210,6 +210,14 @@ static irqreturn_t idio_16_irq_handler(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+#define IDIO_16_NGPIO 32
+static const char *idio_16_names[IDIO_16_NGPIO] = {
+ "OUT0", "OUT1", "OUT2", "OUT3", "OUT4", "OUT5", "OUT6", "OUT7",
+ "OUT8", "OUT9", "OUT10", "OUT11", "OUT12", "OUT13", "OUT14", "OUT15",
+ "IIN0", "IIN1", "IIN2", "IIN3", "IIN4", "IIN5", "IIN6", "IIN7",
+ "IIN8", "IIN9", "IIN10", "IIN11", "IIN12", "IIN13", "IIN14", "IIN15"
+};
+
static int idio_16_probe(struct device *dev, unsigned int id)
{
struct idio_16_gpio *idio16gpio;
@@ -230,7 +238,8 @@ static int idio_16_probe(struct device *dev, unsigned int
id)
idio16gpio->chip.parent = dev;
idio16gpio->chip.owner = THIS_MODULE;
idio16gpio->chip.base = -1;
- idio16gpio->chip.ngpio = 32;
+ idio16gpio->chip.ngpio = IDIO_16_NGPIO;
+ idio16gpio->chip.names = idio_16_names;
idio16gpio->chip.get_direction = idio_16_gpio_get_direction;
idio16gpio->chip.direction_input = idio_16_gpio_direction_input;
idio16gpio->chip.direction_output = idio_16_gpio_direction_output;
--
2.11.0
[PATCH 4/5] gpio: gpio-mm: Add support for GPIO names
This patch sets the gpio_chip names option with an array of GPIO line
names that match the manual documentation for the Diamond Systems
GPIO-MM. This should make it easier for users to identify which GPIO
line corresponds to a respective GPIO pin on the device.
Signed-off-by: William Breathitt Gray
---
drivers/gpio/gpio-gpio-mm.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-gpio-mm.c b/drivers/gpio/gpio-gpio-mm.c
index 393c8f9cf30d..bf74cc55ab44 100644
--- a/drivers/gpio/gpio-gpio-mm.c
+++ b/drivers/gpio/gpio-gpio-mm.c
@@ -230,6 +230,18 @@ static void gpiomm_gpio_set_multiple(struct gpio_chip
*chip,
}
}
+#define GPIOMM_NGPIO 48
+static const char *gpiomm_names[GPIOMM_NGPIO] = {
+ "Port 1A0", "Port 1A1", "Port 1A2", "Port 1A3", "Port 1A4", "Port 1A5",
+ "Port 1A6", "Port 1A7", "Port 1B0", "Port 1B1", "Port 1B2", "Port 1B3",
+ "Port 1B4", "Port 1B5", "Port 1B6", "Port 1B7", "Port 1C0", "Port 1C1",
+ "Port 1C2", "Port 1C3", "Port 1C4", "Port 1C5", "Port 1C6", "Port 1C7",
+ "Port 2A0", "Port 2A1", "Port 2A2", "Port 2A3", "Port 2A4", "Port 2A5",
+ "Port 2A6", "Port 2A7", "Port 2B0", "Port 2B1", "Port 2B2", "Port 2B3",
+ "Port 2B4", "Port 2B5", "Port 2B6", "Port 2B7", "Port 2C0", "Port 2C1",
+ "Port 2C2", "Port 2C3", "Port 2C4", "Port 2C5", "Port 2C6", "Port 2C7",
+};
+
static int gpiomm_probe(struct device *dev, unsigned int id)
{
struct gpiomm_gpio *gpiommgpio;
@@ -250,7 +262,8 @@ static int gpiomm_probe(struct device *dev, unsigned int id)
gpiommgpio->chip.parent = dev;
gpiommgpio->chip.owner = THIS_MODULE;
gpiommgpio->chip.base = -1;
- gpiommgpio->chip.ngpio = 48;
+ gpiommgpio->chip.ngpio = GPIOMM_NGPIO;
+ gpiommgpio->chip.names = gpiomm_names;
gpiommgpio->chip.get_direction = gpiomm_gpio_get_direction;
gpiommgpio->chip.direction_input = gpiomm_gpio_direction_input;
gpiommgpio->chip.direction_output = gpiomm_gpio_direction_output;
--
2.11.0
[RFC 2/3] kernel: Wire up system power framework
From: Thierry Reding
Instead of relying on the globally defined pm_power_off_prepare() and
pm_power_off() function pointers, use the equivalent global functions
from the system-power framework.
The system-power framework implements a fallback that relies on these
global functions in case no system power chips have been registered.
Signed-off-by: Thierry Reding
---
kernel/reboot.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/kernel/reboot.c b/kernel/reboot.c
index bd30a973fe94..ea075e285832 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
/*
@@ -257,8 +258,7 @@ EXPORT_SYMBOL_GPL(kernel_halt);
void kernel_power_off(void)
{
kernel_shutdown_prepare(SYSTEM_POWER_OFF);
- if (pm_power_off_prepare)
- pm_power_off_prepare();
+ system_power_off_prepare();
migrate_to_reboot_cpu();
syscore_shutdown();
pr_emerg("Power down\n");
@@ -305,10 +305,11 @@ SYSCALL_DEFINE4(reboot, int, magic1, int, magic2,
unsigned int, cmd,
if (ret)
return ret;
- /* Instead of trying to make the power_off code look like
-* halt when pm_power_off is not set do it the easy way.
+ /*
+* Instead of trying to make the power_off code look like halt when
+* power off is not supported do it the easy way.
*/
- if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) && !pm_power_off)
+ if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) && !system_can_power_off())
cmd = LINUX_REBOOT_CMD_HALT;
mutex_lock(&reboot_mutex);
--
2.11.0
[PATCH 1/2] ARM: cache-uniphier: include instead of
Nothing in this header file depends on . Rather, should be included for -ENODEV. Signed-off-by: Masahiro Yamada --- KernelVersion: 4.10-rc1 arch/arm/include/asm/hardware/cache-uniphier.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h b/arch/arm/include/asm/hardware/cache-uniphier.h index eaa60da..0ef42ae 100644 --- a/arch/arm/include/asm/hardware/cache-uniphier.h +++ b/arch/arm/include/asm/hardware/cache-uniphier.h @@ -16,7 +16,7 @@ #ifndef __CACHE_UNIPHIER_H #define __CACHE_UNIPHIER_H -#include +#include #ifdef CONFIG_CACHE_UNIPHIER int uniphier_cache_init(void); -- 2.7.4
[PATCH 2/2] ARM: cache-uniphier: clean up active way setup code
Now, the active way setup function is called with a fixed value zero
for the second argument. The code can be simpler.
Signed-off-by: Masahiro Yamada
---
KernelVersion: 4.10-rc1
arch/arm/mm/cache-uniphier.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mm/cache-uniphier.c b/arch/arm/mm/cache-uniphier.c
index dfe97b4..f57b080 100644
--- a/arch/arm/mm/cache-uniphier.c
+++ b/arch/arm/mm/cache-uniphier.c
@@ -15,6 +15,7 @@
#define pr_fmt(fmt)"uniphier: " fmt
+#include
#include
#include
#include
@@ -71,8 +72,7 @@
* @ctrl_base: virtual base address of control registers
* @rev_base: virtual base address of revision registers
* @op_base: virtual base address of operation registers
- * @way_present_mask: each bit specifies if the way is present
- * @way_locked_mask: each bit specifies if the way is locked
+ * @way_mask: each bit specifies if the way is present
* @nsets: number of associativity sets
* @line_size: line size in bytes
* @range_op_max_size: max size that can be handled by a single range operation
@@ -83,8 +83,7 @@ struct uniphier_cache_data {
void __iomem *rev_base;
void __iomem *op_base;
void __iomem *way_ctrl_base;
- u32 way_present_mask;
- u32 way_locked_mask;
+ u32 way_mask;
u32 nsets;
u32 line_size;
u32 range_op_max_size;
@@ -234,17 +233,13 @@ static void __uniphier_cache_enable(struct
uniphier_cache_data *data, bool on)
writel_relaxed(val, data->ctrl_base + UNIPHIER_SSCC);
}
-static void __init __uniphier_cache_set_locked_ways(
- struct uniphier_cache_data *data,
- u32 way_mask)
+static void __init __uniphier_cache_set_active_ways(
+ struct uniphier_cache_data *data)
{
unsigned int cpu;
- data->way_locked_mask = way_mask & data->way_present_mask;
-
for_each_possible_cpu(cpu)
- writel_relaxed(~data->way_locked_mask & data->way_present_mask,
- data->way_ctrl_base + 4 * cpu);
+ writel_relaxed(data->way_mask, data->way_ctrl_base + 4 * cpu);
}
static void uniphier_cache_maint_range(unsigned long start, unsigned long end,
@@ -307,7 +302,7 @@ static void __init uniphier_cache_enable(void)
list_for_each_entry(data, &uniphier_cache_list, list) {
__uniphier_cache_enable(data, true);
- __uniphier_cache_set_locked_ways(data, 0);
+ __uniphier_cache_set_active_ways(data);
}
}
@@ -382,8 +377,8 @@ static int __init __uniphier_cache_init(struct device_node
*np,
goto err;
}
- data->way_present_mask =
- ((u32)1 << cache_size / data->nsets / data->line_size) - 1;
+ data->way_mask = GENMASK(cache_size / data->nsets / data->line_size - 1,
+0);
data->ctrl_base = of_iomap(np, 0);
if (!data->ctrl_base) {
--
2.7.4
[PATCH] iio: stx104: Add support for GPIO names
This patch sets the gpio_chip names option with an array of GPIO line
names that match the manual documentation for the Apex Embedded Systems
STX104. This should make it easier for users to identify which GPIO line
corresponds to a respective GPIO pin on the device.
Signed-off-by: William Breathitt Gray
---
drivers/iio/adc/stx104.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/stx104.c b/drivers/iio/adc/stx104.c
index c56ff286695d..04b94fcd5acf 100644
--- a/drivers/iio/adc/stx104.c
+++ b/drivers/iio/adc/stx104.c
@@ -266,6 +266,11 @@ static void stx104_gpio_set(struct gpio_chip *chip,
unsigned int offset,
spin_unlock_irqrestore(&stx104gpio->lock, flags);
}
+#define STX104_NGPIO 8
+static const char *stx104_names[STX104_NGPIO] = {
+ "DIN0", "DIN1", "DIN2", "DIN3", "DOUT0", "DOUT1", "DOUT2", "DOUT3"
+};
+
static int stx104_probe(struct device *dev, unsigned int id)
{
struct iio_dev *indio_dev;
@@ -324,7 +329,8 @@ static int stx104_probe(struct device *dev, unsigned int id)
stx104gpio->chip.parent = dev;
stx104gpio->chip.owner = THIS_MODULE;
stx104gpio->chip.base = -1;
- stx104gpio->chip.ngpio = 8;
+ stx104gpio->chip.ngpio = STX104_NGPIO;
+ stx104gpio->chip.names = stx104_names;
stx104gpio->chip.get_direction = stx104_gpio_get_direction;
stx104gpio->chip.direction_input = stx104_gpio_direction_input;
stx104gpio->chip.direction_output = stx104_gpio_direction_output;
--
2.11.0
Re: [RFC v2 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer
On Sun, Jan 29, 2017 at 7:01 AM, Marc Zyngier wrote:
> On Fri, Jan 27 2017 at 01:04:53 AM, Jintack Lim
> wrote:
>> Now that we have a separate structure for timer context, make functions
>> general so that they can work with any timer context, not just the
>
> generic?
yes, thanks!
>
>> virtual timer context. This does not change the virtual timer
>> functionality.
>>
>> Signed-off-by: Jintack Lim
>> ---
>> arch/arm/kvm/arm.c | 2 +-
>> include/kvm/arm_arch_timer.h | 3 ++-
>> virt/kvm/arm/arch_timer.c| 55
>> ++--
>> 3 files changed, 30 insertions(+), 30 deletions(-)
>>
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 9d74464..9a34a3c 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -301,7 +301,7 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
>>
>> int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
>> {
>> - return kvm_timer_should_fire(vcpu);
>> + return kvm_timer_should_fire(vcpu, vcpu_vtimer(vcpu));
>> }
>>
>> void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu)
>> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
>> index 1b9c988..d921d20 100644
>> --- a/include/kvm/arm_arch_timer.h
>> +++ b/include/kvm/arm_arch_timer.h
>> @@ -67,7 +67,8 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>> u64 kvm_arm_timer_get_reg(struct kvm_vcpu *, u64 regid);
>> int kvm_arm_timer_set_reg(struct kvm_vcpu *, u64 regid, u64 value);
>>
>> -bool kvm_timer_should_fire(struct kvm_vcpu *vcpu);
>> +bool kvm_timer_should_fire(struct kvm_vcpu *vcpu,
>> +struct arch_timer_context *timer_ctx);
>> void kvm_timer_schedule(struct kvm_vcpu *vcpu);
>> void kvm_timer_unschedule(struct kvm_vcpu *vcpu);
>>
>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>> index fa4c042..f72005a 100644
>> --- a/virt/kvm/arm/arch_timer.c
>> +++ b/virt/kvm/arm/arch_timer.c
>> @@ -98,13 +98,13 @@ static void kvm_timer_inject_irq_work(struct work_struct
>> *work)
>> kvm_vcpu_kick(vcpu);
>> }
>>
>> -static u64 kvm_timer_compute_delta(struct kvm_vcpu *vcpu)
>> +static u64 kvm_timer_compute_delta(struct kvm_vcpu *vcpu,
>> +struct arch_timer_context *timer_ctx)
>> {
>> u64 cval, now;
>> - struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>>
>> - cval = vtimer->cnt_cval;
>> - now = kvm_phys_timer_read() - vtimer->cntvoff;
>> + cval = timer_ctx->cnt_cval;
>> + now = kvm_phys_timer_read() - timer_ctx->cntvoff;
>>
>> if (now < cval) {
>> u64 ns;
>> @@ -133,7 +133,7 @@ static enum hrtimer_restart kvm_timer_expire(struct
>> hrtimer *hrt)
>>* PoV (NTP on the host may have forced it to expire
>>* early). If we should have slept longer, restart it.
>>*/
>> - ns = kvm_timer_compute_delta(vcpu);
>> + ns = kvm_timer_compute_delta(vcpu, vcpu_vtimer(vcpu));
>> if (unlikely(ns)) {
>> hrtimer_forward_now(hrt, ns_to_ktime(ns));
>> return HRTIMER_RESTART;
>> @@ -143,42 +143,40 @@ static enum hrtimer_restart kvm_timer_expire(struct
>> hrtimer *hrt)
>> return HRTIMER_NORESTART;
>> }
>>
>> -static bool kvm_timer_irq_can_fire(struct kvm_vcpu *vcpu)
>> +static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx)
>> {
>> - struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>> -
>> - return !(vtimer->cnt_ctl & ARCH_TIMER_CTRL_IT_MASK) &&
>> - (vtimer->cnt_ctl & ARCH_TIMER_CTRL_ENABLE);
>> + return !(timer_ctx->cnt_ctl & ARCH_TIMER_CTRL_IT_MASK) &&
>> + (timer_ctx->cnt_ctl & ARCH_TIMER_CTRL_ENABLE);
>> }
>>
>> -bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
>> +bool kvm_timer_should_fire(struct kvm_vcpu *vcpu,
>> +struct arch_timer_context *timer_ctx)
>> {
>> - struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>> u64 cval, now;
>>
>> - if (!kvm_timer_irq_can_fire(vcpu))
>> + if (!kvm_timer_irq_can_fire(timer_ctx))
>> return false;
>>
>> - cval = vtimer->cnt_cval;
>> - now = kvm_phys_timer_read() - vtimer->cntvoff;
>> + cval = timer_ctx->cnt_cval;
>> + now = kvm_phys_timer_read() - timer_ctx->cntvoff;
>>
>> return cval <= now;
>> }
>>
>> -static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
>> +static void kvm_timer_update_mapped_irq(struct kvm_vcpu *vcpu, bool
>> new_level,
>> + struct arch_timer_context *timer_ctx)
>> {
>> int ret;
>> - struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>>
>> BUG_ON(!vgic_initialized(vcpu->kvm));
>>
>> - vtimer->active_cleared_last = false;
>> - vtimer->irq.level = new_level;
>> - trace_kvm_timer_update_irq(vcpu->vcpu_id, vtimer->irq.irq,
>> -vtimer->irq.level);
>> + timer_ctx->active_cleared_last = false;
>> + timer_ctx->irq.lev
Re: [PATCH 9/9] net, bpf: use kvzalloc helper
Andrew, please ignore this one.
On Mon 30-01-17 10:49:40, Michal Hocko wrote:
> From: Michal Hocko
>
> both bpf_map_area_alloc and xt_alloc_table_info try really hard to
> play nicely with large memory requests which can be triggered from
> the userspace (by an admin). See 5bad87348c70 ("netfilter: x_tables:
> avoid warn and OOM killer on vmalloc call") resp. d407bd25a204 ("bpf:
> don't trigger OOM killer under pressure with map alloc").
>
> The current allocation pattern strongly resembles kvmalloc helper except
> for one thing __GFP_NORETRY is not used for the vmalloc fallback. The
> main reason why kvmalloc doesn't really support __GFP_NORETRY is
> because vmalloc doesn't support this flag properly and it is far from
> straightforward to make it understand it because there are some hard
> coded GFP_KERNEL allocation deep in the call chains. This patch simply
> replaces the open coded variants with kvmalloc and puts a note to
> push on MM people to support __GFP_NORETRY in kvmalloc it this turns out
> to be really needed along with OOM report pointing at vmalloc.
>
> If there is an immediate need and no full support yet then
> kvmalloc(size, gfp | __GFP_NORETRY)
> will work as good as __vmalloc(gfp | __GFP_NORETRY) - in other words it
> might trigger the OOM in some cases.
>
> Cc: Alexei Starovoitov
> Cc: Andrey Konovalov
> Cc: Marcelo Ricardo Leitner
> Cc: Pablo Neira Ayuso
> Acked-by: Daniel Borkmann
> Signed-off-by: Michal Hocko
> ---
> kernel/bpf/syscall.c | 19 +--
> net/netfilter/x_tables.c | 16 ++--
> 2 files changed, 11 insertions(+), 24 deletions(-)
>
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 08a4d287226b..3d38c7a51e1a 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -54,21 +54,12 @@ void bpf_register_map_type(struct bpf_map_type_list *tl)
>
> void *bpf_map_area_alloc(size_t size)
> {
> - /* We definitely need __GFP_NORETRY, so OOM killer doesn't
> - * trigger under memory pressure as we really just want to
> - * fail instead.
> + /*
> + * FIXME: we would really like to not trigger the OOM killer and rather
> + * fail instead. This is not supported right now. Please nag MM people
> + * if these OOM start bothering people.
>*/
> - const gfp_t flags = __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO;
> - void *area;
> -
> - if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) {
> - area = kmalloc(size, GFP_USER | flags);
> - if (area != NULL)
> - return area;
> - }
> -
> - return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM | flags,
> - PAGE_KERNEL);
> + return kvzalloc(size, GFP_USER);
> }
>
> void bpf_map_area_free(void *area)
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index d529989f5791..ba8ba633da72 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -995,16 +995,12 @@ struct xt_table_info *xt_alloc_table_info(unsigned int
> size)
> if ((SMP_ALIGN(size) >> PAGE_SHIFT) + 2 > totalram_pages)
> return NULL;
>
> - if (sz <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER))
> - info = kmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
> - if (!info) {
> - info = __vmalloc(sz, GFP_KERNEL | __GFP_NOWARN |
> - __GFP_NORETRY | __GFP_HIGHMEM,
> - PAGE_KERNEL);
> - if (!info)
> - return NULL;
> - }
> - memset(info, 0, sizeof(*info));
> + /*
> + * FIXME: we would really like to not trigger the OOM killer and rather
> + * fail instead. This is not supported right now. Please nag MM people
> + * if these OOM start bothering people.
> + */
> + info = kvzalloc(sz, GFP_KERNEL);
> info->size = size;
> return info;
> }
> --
> 2.11.0
>
--
Michal Hocko
SUSE Labs
Re: [RFC V2 02/12] mm: Isolate HugeTLB allocations away from CDM nodes
On 01/29/2017 07:35 PM, Anshuman Khandual wrote: > HugeTLB allocation/release/accounting currently spans across all the nodes > under N_MEMORY node mask. Coherent memory nodes should not be part of these > allocations. So use system_ram() call to fetch system RAM only nodes on the > platform which can then be used for HugeTLB allocation purpose instead of > N_MEMORY node mask. This isolates coherent device memory nodes from HugeTLB > allocations. Does this end up making it impossible to use hugetlbfs to access device memory?
Re: [RFC v2 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer
Hi Christoffer,
On Mon, Jan 30, 2017 at 9:49 AM, Christoffer Dall
wrote:
> On Thu, Jan 26, 2017 at 08:04:53PM -0500, Jintack Lim wrote:
>> Now that we have a separate structure for timer context, make functions
>> general so that they can work with any timer context, not just the
>> virtual timer context. This does not change the virtual timer
>> functionality.
>>
>> Signed-off-by: Jintack Lim
>> ---
>> arch/arm/kvm/arm.c | 2 +-
>> include/kvm/arm_arch_timer.h | 3 ++-
>> virt/kvm/arm/arch_timer.c| 55
>> ++--
>> 3 files changed, 30 insertions(+), 30 deletions(-)
>>
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 9d74464..9a34a3c 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -301,7 +301,7 @@ void kvm_arch_vcpu_destroy(struct kvm_vcpu *vcpu)
>>
>> int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu)
>> {
>> - return kvm_timer_should_fire(vcpu);
>> + return kvm_timer_should_fire(vcpu, vcpu_vtimer(vcpu));
>> }
>>
>> void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu)
>> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
>> index 1b9c988..d921d20 100644
>> --- a/include/kvm/arm_arch_timer.h
>> +++ b/include/kvm/arm_arch_timer.h
>> @@ -67,7 +67,8 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>> u64 kvm_arm_timer_get_reg(struct kvm_vcpu *, u64 regid);
>> int kvm_arm_timer_set_reg(struct kvm_vcpu *, u64 regid, u64 value);
>>
>> -bool kvm_timer_should_fire(struct kvm_vcpu *vcpu);
>> +bool kvm_timer_should_fire(struct kvm_vcpu *vcpu,
>> +struct arch_timer_context *timer_ctx);
>> void kvm_timer_schedule(struct kvm_vcpu *vcpu);
>> void kvm_timer_unschedule(struct kvm_vcpu *vcpu);
>>
>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>> index fa4c042..f72005a 100644
>> --- a/virt/kvm/arm/arch_timer.c
>> +++ b/virt/kvm/arm/arch_timer.c
>> @@ -98,13 +98,13 @@ static void kvm_timer_inject_irq_work(struct work_struct
>> *work)
>> kvm_vcpu_kick(vcpu);
>> }
>>
>> -static u64 kvm_timer_compute_delta(struct kvm_vcpu *vcpu)
>> +static u64 kvm_timer_compute_delta(struct kvm_vcpu *vcpu,
>> +struct arch_timer_context *timer_ctx)
>
> do you need the vcpu parameter here?
No, I'll remove it.
>
>> {
>> u64 cval, now;
>> - struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>>
>> - cval = vtimer->cnt_cval;
>> - now = kvm_phys_timer_read() - vtimer->cntvoff;
>> + cval = timer_ctx->cnt_cval;
>> + now = kvm_phys_timer_read() - timer_ctx->cntvoff;
>>
>> if (now < cval) {
>> u64 ns;
>> @@ -133,7 +133,7 @@ static enum hrtimer_restart kvm_timer_expire(struct
>> hrtimer *hrt)
>>* PoV (NTP on the host may have forced it to expire
>>* early). If we should have slept longer, restart it.
>>*/
>> - ns = kvm_timer_compute_delta(vcpu);
>> + ns = kvm_timer_compute_delta(vcpu, vcpu_vtimer(vcpu));
>> if (unlikely(ns)) {
>> hrtimer_forward_now(hrt, ns_to_ktime(ns));
>> return HRTIMER_RESTART;
>> @@ -143,42 +143,40 @@ static enum hrtimer_restart kvm_timer_expire(struct
>> hrtimer *hrt)
>> return HRTIMER_NORESTART;
>> }
>>
>> -static bool kvm_timer_irq_can_fire(struct kvm_vcpu *vcpu)
>> +static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx)
>> {
>> - struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>> -
>> - return !(vtimer->cnt_ctl & ARCH_TIMER_CTRL_IT_MASK) &&
>> - (vtimer->cnt_ctl & ARCH_TIMER_CTRL_ENABLE);
>> + return !(timer_ctx->cnt_ctl & ARCH_TIMER_CTRL_IT_MASK) &&
>> + (timer_ctx->cnt_ctl & ARCH_TIMER_CTRL_ENABLE);
>> }
>>
>> -bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
>> +bool kvm_timer_should_fire(struct kvm_vcpu *vcpu,
>> +struct arch_timer_context *timer_ctx)
>
> do you need the vcpu parameter here?
No, I'll remove it.
Thanks,
Jintack
>
>> {
>> - struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>> u64 cval, now;
>>
>> - if (!kvm_timer_irq_can_fire(vcpu))
>> + if (!kvm_timer_irq_can_fire(timer_ctx))
>> return false;
>>
>> - cval = vtimer->cnt_cval;
>> - now = kvm_phys_timer_read() - vtimer->cntvoff;
>> + cval = timer_ctx->cnt_cval;
>> + now = kvm_phys_timer_read() - timer_ctx->cntvoff;
>>
>> return cval <= now;
>> }
>>
>> -static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
>> +static void kvm_timer_update_mapped_irq(struct kvm_vcpu *vcpu, bool
>> new_level,
>> + struct arch_timer_context *timer_ctx)
>> {
>> int ret;
>> - struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>>
>> BUG_ON(!vgic_initialized(vcpu->kvm));
>>
>> - vtimer->active_cleared_last = false;
>> - vtimer->irq.level = new_level;
>> - trace_kvm_timer_update_irq(vcpu->vcpu_id, vtimer->irq
Re: [PATCH 09/14] x86/fpu: Change 'size_total' parameter to unsigned and standardize the size checks in copy_xstate_to_*()
On Thu, Jan 26, 2017 at 11:22:54AM +0100, Ingo Molnar wrote:
> 'size_total' is derived from an unsigned input parameter - and then converted
> to 'int' and checked for negative ranges:
>
> if (size_total < 0 || offset < size_total) {
>
> This conversion and the checks are unnecessary obfuscation, reject overly
> large requested copy sizes outright and simplify the underlying code.
>
> Reported-by: Rik van Riel
> Cc: Andy Lutomirski
> Cc: Borislav Petkov
> Cc: Dave Hansen
> Cc: Fenghua Yu
> Cc: H. Peter Anvin
> Cc: Linus Torvalds
> Cc: Oleg Nesterov
> Cc: Thomas Gleixner
> Cc: Yu-cheng Yu
> Cc: Fenghua Yu
> Signed-off-by: Ingo Molnar
> ---
> arch/x86/kernel/fpu/xstate.c | 32 +++-
> 1 file changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index 8f9da89015e6..cceabca485c8 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -924,15 +924,11 @@ int arch_set_user_pkey_access(struct task_struct *tsk,
> int pkey,
> * the source data pointer or increment pos, count, kbuf, and ubuf.
> */
> static inline int
> -__copy_xstate_to_kernel(void *kbuf,
> - const void *data,
> - unsigned int offset, unsigned int size, int size_total)
> +__copy_xstate_to_kernel(void *kbuf, const void *data,
> + unsigned int offset, unsigned int size, unsigned int
> size_total)
> {
> - if (!size)
> - return 0;
> -
> - if (size_total < 0 || offset < size_total) {
> - unsigned int copy = size_total < 0 ? size : min(size,
> size_total - offset);
> + if (offset < size_total) {
> + unsigned int copy = min(size, size_total - offset);
>
> memcpy(kbuf + offset, data, copy);
> }
> @@ -985,12 +981,13 @@ int copy_xstate_to_kernel(void *kbuf, struct
> xregs_state *xsave, unsigned int of
> offset = xstate_offsets[i];
> size = xstate_sizes[i];
>
> + /* The next component has to fit fully into the output
> buffer: */
> + if (offset + size > size_total)
> + break;
This makes sense, but would be different from the non-compacted format path
where this
rule is not enforced. Do we want to unify both?
Yu-cheng
[PATCH 1/2] watchdog: sama5d4: Cache MR instead of a partial config
.config is used to cache a part of WDT_MR at probe time and is not used
afterwards. Instead of doing that, actually cache MR and avoid reading it
every time it is modified.
Signed-off-by: Alexandre Belloni
---
drivers/watchdog/sama5d4_wdt.c | 45 ++
1 file changed, 19 insertions(+), 26 deletions(-)
diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
index a49634cdc1cc..6dd07bef515a 100644
--- a/drivers/watchdog/sama5d4_wdt.c
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -28,7 +28,7 @@
struct sama5d4_wdt {
struct watchdog_device wdd;
void __iomem*reg_base;
- u32 config;
+ u32 mr;
};
static int wdt_timeout = WDT_DEFAULT_TIMEOUT;
@@ -53,11 +53,9 @@ MODULE_PARM_DESC(nowayout,
static int sama5d4_wdt_start(struct watchdog_device *wdd)
{
struct sama5d4_wdt *wdt = watchdog_get_drvdata(wdd);
- u32 reg;
- reg = wdt_read(wdt, AT91_WDT_MR);
- reg &= ~AT91_WDT_WDDIS;
- wdt_write(wdt, AT91_WDT_MR, reg);
+ wdt->mr &= ~AT91_WDT_WDDIS;
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr);
return 0;
}
@@ -65,11 +63,9 @@ static int sama5d4_wdt_start(struct watchdog_device *wdd)
static int sama5d4_wdt_stop(struct watchdog_device *wdd)
{
struct sama5d4_wdt *wdt = watchdog_get_drvdata(wdd);
- u32 reg;
- reg = wdt_read(wdt, AT91_WDT_MR);
- reg |= AT91_WDT_WDDIS;
- wdt_write(wdt, AT91_WDT_MR, reg);
+ wdt->mr |= AT91_WDT_WDDIS;
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr);
return 0;
}
@@ -88,14 +84,12 @@ static int sama5d4_wdt_set_timeout(struct watchdog_device
*wdd,
{
struct sama5d4_wdt *wdt = watchdog_get_drvdata(wdd);
u32 value = WDT_SEC2TICKS(timeout);
- u32 reg;
- reg = wdt_read(wdt, AT91_WDT_MR);
- reg &= ~AT91_WDT_WDV;
- reg &= ~AT91_WDT_WDD;
- reg |= AT91_WDT_SET_WDV(value);
- reg |= AT91_WDT_SET_WDD(value);
- wdt_write(wdt, AT91_WDT_MR, reg);
+ wdt->mr &= ~AT91_WDT_WDV;
+ wdt->mr &= ~AT91_WDT_WDD;
+ wdt->mr |= AT91_WDT_SET_WDV(value);
+ wdt->mr |= AT91_WDT_SET_WDD(value);
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr);
wdd->timeout = timeout;
@@ -132,19 +126,19 @@ static int of_sama5d4_wdt_init(struct device_node *np,
struct sama5d4_wdt *wdt)
{
const char *tmp;
- wdt->config = AT91_WDT_WDDIS;
+ wdt->mr = AT91_WDT_WDDIS;
if (!of_property_read_string(np, "atmel,watchdog-type", &tmp) &&
!strcmp(tmp, "software"))
- wdt->config |= AT91_WDT_WDFIEN;
+ wdt->mr |= AT91_WDT_WDFIEN;
else
- wdt->config |= AT91_WDT_WDRSTEN;
+ wdt->mr |= AT91_WDT_WDRSTEN;
if (of_property_read_bool(np, "atmel,idle-halt"))
- wdt->config |= AT91_WDT_WDIDLEHLT;
+ wdt->mr |= AT91_WDT_WDIDLEHLT;
if (of_property_read_bool(np, "atmel,dbg-halt"))
- wdt->config |= AT91_WDT_WDDBGHLT;
+ wdt->mr |= AT91_WDT_WDDBGHLT;
return 0;
}
@@ -163,11 +157,10 @@ static int sama5d4_wdt_init(struct sama5d4_wdt *wdt)
reg &= ~AT91_WDT_WDDIS;
wdt_write(wdt, AT91_WDT_MR, reg);
- reg = wdt->config;
- reg |= AT91_WDT_SET_WDD(value);
- reg |= AT91_WDT_SET_WDV(value);
+ wdt->mr |= AT91_WDT_SET_WDD(value);
+ wdt->mr |= AT91_WDT_SET_WDV(value);
- wdt_write(wdt, AT91_WDT_MR, reg);
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr);
return 0;
}
@@ -211,7 +204,7 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
return ret;
}
- if ((wdt->config & AT91_WDT_WDFIEN) && irq) {
+ if ((wdt->mr & AT91_WDT_WDFIEN) && irq) {
ret = devm_request_irq(&pdev->dev, irq, sama5d4_wdt_irq_handler,
IRQF_SHARED | IRQF_IRQPOLL |
IRQF_NO_SUSPEND, pdev->name, pdev);
--
2.11.0
[PATCH 2/2] watchdog: sama5d4: Implement resume hook
When resuming for the deepest state on sama5d2, it is necessary to restore
MR as the registers are lost.
Signed-off-by: Alexandre Belloni
---
drivers/watchdog/sama5d4_wdt.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
index 6dd07bef515a..de8ff10a032e 100644
--- a/drivers/watchdog/sama5d4_wdt.c
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -258,11 +258,28 @@ static const struct of_device_id sama5d4_wdt_of_match[] =
{
};
MODULE_DEVICE_TABLE(of, sama5d4_wdt_of_match);
+#ifdef CONFIG_PM_SLEEP
+static int sama5d4_wdt_resume(struct device *dev)
+{
+ struct sama5d4_wdt *wdt = dev_get_drvdata(dev);
+
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr & ~AT91_WDT_WDDIS);
+ if (wdt->mr & AT91_WDT_WDDIS)
+ wdt_write(wdt, AT91_WDT_MR, wdt->mr);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(sama5d4_wdt_pm_ops, NULL,
+sama5d4_wdt_resume);
+
static struct platform_driver sama5d4_wdt_driver = {
.probe = sama5d4_wdt_probe,
.remove = sama5d4_wdt_remove,
.driver = {
.name = "sama5d4_wdt",
+ .pm = &sama5d4_wdt_pm_ops,
.of_match_table = sama5d4_wdt_of_match,
}
};
--
2.11.0
Re: [PATCH v8 07/12] dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings
On Sat, Jan 28, 2017 at 4:42 PM, Peter Rosin wrote: > On 2017-01-27 20:39, Rob Herring wrote: >> On Wed, Jan 18, 2017 at 04:57:10PM +0100, Peter Rosin wrote: >>> Describe how a generic multiplexer controller is used to mux an i2c bus. >>> >>> Acked-by: Jonathan Cameron >>> Signed-off-by: Peter Rosin >>> --- >>> .../devicetree/bindings/i2c/i2c-mux-simple.txt | 81 >>> ++ >>> 1 file changed, 81 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt >>> >>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt >>> b/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt >>> new file mode 100644 >>> index ..253d5027843b >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-simple.txt >>> @@ -0,0 +1,81 @@ >>> +Simple I2C Bus Mux >>> + >>> +This binding describes an I2C bus multiplexer that uses a mux controller >>> +from the mux subsystem to route the I2C signals. >>> + >>> + .-. .-. >>> + | dev | | dev | >>> +..'-' '-' >>> +| SoC| || >>> +|| .+' >>> +| .--. | .--+child bus A, on MUX value set to 0 >>> +| | I2C |-|--| Mux | >>> +| '--' | '--+---+child bus B, on MUX value set to 1 >>> +| .--. | |'--++. >>> +| | MUX- | | | ||| >>> +| | Ctrl |-|-+.-. .-. .-. >>> +| '--' | | dev | | dev | | dev | >>> +'' '-' '-' '-' >>> + >>> +Required properties: >>> +- compatible: i2c-mux-simple,mux-locked or i2c-mux-simple,parent-locked >> >> Not a fan of using "simple" nor the ','. Perhaps lock type should be >> separate property. > > How about just i2c-mux for the compatible? Because i2c-mux-mux (which > follows the naming of previous i2c muxes) looks really stupid. Or > perhaps i2c-mux-generic? I like "generic" only slightly more than "simple". :) If the mux is gpio controlled, then it should still be called i2c-gpio-mux. Let's not invent brand new bindings when current ones are easily extended. We already have pretty generic names here, let's not make them more generic. > > I'm also happy to have the lock type as a separate property. One lock > type, e.g. parent-locked, could be the default and adding a 'mux-locked' > property could change that. Would that be ok? I prefer this. Then existing bindings can use it. > Or should it be a requirement that one of 'mux-locked'/'parent-locked' > is always present? I would make it boolean and make not present be the more common case. Not present could also mean determined via other means as you have today with existing bindings. Maybe then you need both properties. >> I'm not sure I get the mux vs. parent locked fully. How do I determine >> what type I have? We already have bindings for several types of i2c >> muxes. How does the locking annotation fit into those? > > We have briefly discussed this before [1] in the context of i2c-mux-gpio > and i2c-mux-pinctrl, when I added the mux-locked/parent-locked distinction > to the i2c-mux infrastructure (it wasn't named mux-locked/parent-locked > way back then though). There is more detail on what the difference is > between the two in Documentation/i2c/i2c-topology. > > Side note regarding your remark "use an I2C controlled mux instead"; it > appears that I'm not alone [2] with this kind of requirement... > > [1] https://lkml.org/lkml/2016/1/6/437 > [2] http://marc.info/?t=14787795912&r=1&w=2 > > But, now that I have pondered on this for a year or so, I firmly > believe it was a mistake to have the code in i2c-mux-gpio and > i2c-mux-pinctrl automatically try to deduce if the mux should be > mux-locked or parent-locked. It might be easy to make that call > in some trivial cases, but it is not difficult to dream up > scenarios where it would be extremely hard for the code to get > this decision right. It's just fragile. But now we have code in > those two muxes that has unwanted tentacles into the guts of the > gpio and pinctrl subsystems. Hopefully those unwanted tentacles > can be replaced with something based on device links? However, it > is still not hard to come up with scenarios that will require > manual intervention in order to select the right kind of i2c mux > locking. So, I fear that we have inadequate code trying to make a > decision automatically, and that we at some point down the line > will have some impossible case needing a binding that trumps the > heuristic. Why have a heuristic at all in that case? In short, it > should have been a binding from the start, methinks. > > That was a long rant regarding i2c-mux-gpio and i2c-mux-pinctrl. > I obviously think it is bad to have
[RFC 3/3] PM / hibernate: Wire up system-power framework
From: Thierry Reding Use the system-power framework's equivalent to test for power off capability instead of relying on the globally defined pm_power_off() function pointer. The system-power framework implements a fallback that relies on this global function in case no system power chips have been registered. Moving this to the system-power framework allows us to eventually remove any traces of pm_power_off() once all handlers have moved over to the new framework. Signed-off-by: Thierry Reding --- kernel/power/hibernate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c index b26dbc48c75b..e7429ea11e9a 100644 --- a/kernel/power/hibernate.c +++ b/kernel/power/hibernate.c @@ -30,6 +30,7 @@ #include #include #include +#include #include "power.h" @@ -617,7 +618,7 @@ static void power_down(void) case HIBERNATION_PLATFORM: hibernation_platform_enter(); case HIBERNATION_SHUTDOWN: - if (pm_power_off) + if (system_can_power_off()) kernel_power_off(); break; #ifdef CONFIG_SUSPEND -- 2.11.0
Re: [RFC v2 10/10] KVM: arm/arm64: Emulate the EL1 phys timer register access
On 30 January 2017 at 17:08, Jintack Lim wrote: > On Sun, Jan 29, 2017 at 10:44 AM, Marc Zyngier wrote: >> Shouldn't we take the ENABLE bit into account? The ARMv8 ARM version I >> have at hand (version h) seems to indicate that we should, but we should >> check with the latest and greatest... > > Thanks! I was not clear about this. I have ARM ARM version k, and it > says that 'When the value of the ENABLE bit is 0, the ISTATUS field is > UNKNOWN.' So I thought the istatus value doesn't matter if ENABLE is > 0, and just set istatus bit regardless of ENABLE bit. If this is not > what the manual meant, then I'm happy to fix this. It looks like the spec has been relaxed between the doc version that Marc was looking at and the current one. So it's OK for an implementation to either (a) set ISTATUS to 0 if ENABLE is 0, or (b) do what you've done and set ISTATUS according to the timer comparison whether ENABLE is clear or not (or even (c) set ISTATUS to a random value if ENABLE is clear, and other less likely choices). I think we should add a comment to note that it's architecturally UNKNOWN and we've made a choice for our implementation convenience. thanks -- PMM
[PATCH] i2c: at91: ensure state is restored after suspending
When going to suspend, the I2C registers may be lost because the power to
VDDcore is cut. Save them and restore them when resuming.
Signed-off-by: Alexandre Belloni
---
drivers/i2c/busses/i2c-at91.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 0b86c6173e07..633bdd899952 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -140,6 +140,12 @@ struct at91_twi_dev {
unsigned transfer_status;
struct i2c_adapter adapter;
unsigned twi_cwgr_reg;
+ struct {
+ u32 mmr;
+ u32 imr;
+ u32 fmr;
+ u32 fimr;
+ } cache;
struct at91_twi_pdata *pdata;
bool use_dma;
bool use_alt_cmd;
@@ -1172,6 +1178,15 @@ static int at91_twi_runtime_resume(struct device *dev)
static int at91_twi_suspend_noirq(struct device *dev)
{
+ struct at91_twi_dev *twi_dev = dev_get_drvdata(dev);
+
+ twi_dev->cache.mmr = at91_twi_read(twi_dev, AT91_TWI_MMR);
+ twi_dev->cache.imr = at91_twi_read(twi_dev, AT91_TWI_IMR);
+ if (twi_dev->fifo_size) {
+ twi_dev->cache.fmr = at91_twi_read(twi_dev, AT91_TWI_FMR);
+ twi_dev->cache.fimr = at91_twi_read(twi_dev, AT91_TWI_FIMR);
+ }
+
if (!pm_runtime_status_suspended(dev))
at91_twi_runtime_suspend(dev);
@@ -1180,6 +1195,7 @@ static int at91_twi_suspend_noirq(struct device *dev)
static int at91_twi_resume_noirq(struct device *dev)
{
+ struct at91_twi_dev *twi_dev = dev_get_drvdata(dev);
int ret;
if (!pm_runtime_status_suspended(dev)) {
@@ -1191,6 +1207,14 @@ static int at91_twi_resume_noirq(struct device *dev)
pm_runtime_mark_last_busy(dev);
pm_request_autosuspend(dev);
+ at91_init_twi_bus(twi_dev);
+ at91_twi_write(twi_dev, AT91_TWI_MMR, twi_dev->cache.mmr);
+ at91_twi_write(twi_dev, AT91_TWI_IER, twi_dev->cache.imr);
+ if (twi_dev->fifo_size) {
+ at91_twi_write(twi_dev, AT91_TWI_FMR, twi_dev->cache.fmr);
+ at91_twi_write(twi_dev, AT91_TWI_FIER, twi_dev->cache.fimr);
+ }
+
return 0;
}
--
2.11.0
Re: [PATCH 04/14] x86/fpu: Remove 'kbuf' parameter from the copy_xstate_to_user() APIs
On Mon, Jan 30, 2017 at 04:45:21PM +0100, Borislav Petkov wrote: > On Mon, Jan 30, 2017 at 10:57:28AM +0100, Ingo Molnar wrote: > > Would anyone object to using u32 in these prototypes? > > Well, would there be any disadvantage to forcing them to u32? > Potentially by something else wanting to use those interfaces besides > the regset thing and that something else doesn't like u32s? > > Otherwise, I don't see a problem. > > I mean, if 4G are not enough for xstate dimensions then we have a whole > different problem. This function pair was intended to be similar to user_regset_copyout(), user_regset_copyin() used for the standard-format XSAVE area copying. I totally agree it is complex and should be simplified. Why don't we do both places? Yu-cheng
Re: [PATCH 8/9] bcache: use kvmalloc
On Mon 30-01-17 17:47:31, Vlastimil Babka wrote: > On 01/30/2017 10:49 AM, Michal Hocko wrote: > > From: Michal Hocko > > > > bcache_device_init uses kmalloc for small requests and vmalloc for those > > which are larger than 64 pages. This alone is a strange criterion. > > Moreover kmalloc can fallback to vmalloc on the failure. Let's simply > > use kvmalloc instead as it knows how to handle the fallback properly > > I don't see why separate patch, some of the conversions in 5/9 were quite > similar (except comparing with PAGE_SIZE, not 64*PAGE_SIZE), but nevermind. I just found it later so I kept it separate. It can be folded to 5/9 if that makes more sense. > > Cc: Kent Overstreet > > Signed-off-by: Michal Hocko > > Acked-by: Vlastimil Babka Thanks! > > --- > > drivers/md/bcache/super.c | 8 ++-- > > 1 file changed, 2 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c > > index 3a19cbc8b230..4cb6b88a1465 100644 > > --- a/drivers/md/bcache/super.c > > +++ b/drivers/md/bcache/super.c > > @@ -767,16 +767,12 @@ static int bcache_device_init(struct bcache_device > > *d, unsigned block_size, > > } > > > > n = d->nr_stripes * sizeof(atomic_t); > > - d->stripe_sectors_dirty = n < PAGE_SIZE << 6 > > - ? kzalloc(n, GFP_KERNEL) > > - : vzalloc(n); > > + d->stripe_sectors_dirty = kvzalloc(n, GFP_KERNEL); > > if (!d->stripe_sectors_dirty) > > return -ENOMEM; > > > > n = BITS_TO_LONGS(d->nr_stripes) * sizeof(unsigned long); > > - d->full_dirty_stripes = n < PAGE_SIZE << 6 > > - ? kzalloc(n, GFP_KERNEL) > > - : vzalloc(n); > > + d->full_dirty_stripes = kvzalloc(n, GFP_KERNEL); > > if (!d->full_dirty_stripes) > > return -ENOMEM; > > > > -- Michal Hocko SUSE Labs
[GIT PULL rcu/next] RCU commits for 4.11
Hello, Ingo, This pull request contains the following changes: 1. Documentation updates. http://lkml.kernel.org/r/20170114085032.ga18...@linux.vnet.ibm.com 2. Dyntick updates, consolidating open-coded counter accesses into a well-defined API. http://lkml.kernel.org/r/20170124214602.ga2...@linux.vnet.ibm.com 3. Miscellaneous fixes. http://lkml.kernel.org/r/20170124215111.gb2...@linux.vnet.ibm.com 4. SRCU updates: Simplify algorithm, add formal verification. http://lkml.kernel.org/r/20170124220011.gc2...@linux.vnet.ibm.com 5. Torture-test updates. http://lkml.kernel.org/r/20170114092533.ga23...@linux.vnet.ibm.com All of these changes have been subjected to 0day Test Robot and -next testing, and are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git for-mingo for you to fetch changes up to 31945aa9f14085c81cb3257e51bb210698b78626: Merge branches 'doc.2017.01.15b', 'dyntick.2017.01.23a', 'fixes.2017.01.23a', 'srcu.2017.01.25a' and 'torture.2017.01.15b' into HEAD (2017-01-25 12:56:05 -0800) Byungchul Park (1): rcu: Only dump stalled-tasks stacks if there was a real stall Joel Fernandes (1): llist: Clarify comments about when locking is needed Lance Roy (2): srcu: Implement more-efficient reader counts rcutorture: Add CBMC-based formal verification for SRCU Mathieu Desnoyers (1): Fix: Disable sys_membarrier when nohz_full is enabled Matt Fleming (1): rcu: Enable RCU tracepoints by default to aid in debugging Paul E. McKenney (33): rcu: Design documentation for expedited grace periods doc: Update control-dependencies section of memory-barriers.txt doc: Quick-Quiz answers are now inline doc: Add rcutree.rcu_kick_kthreads to kernel-parameters.txt torture: Add a check for CONFIG_RCU_STALL_COMMON for TINY01 torture: Add CONFIG_PROVE_RCU_REPEATEDLY=y for TINY02 torture: Add tests without slow grace period setup/cleanup torture: Run at least one test with CONFIG_DEBUG_OBJECTS_RCU_HEAD torture: Run one test with DEBUG_LOCK_ALLOC but not PROVE_LOCKING torture: Run a couple scenarios with CONFIG_RCU_EQS_DEBUG torture: Update RCU test scenario documentation torture: Enable DEBUG_OBJECTS_RCU_HEAD for Tiny RCU rcu: Abstract the dynticks momentary-idle operation rcu: Abstract the dynticks snapshot operation lockdep: Make RCU suspicious-access splats use pr_err rcu: Remove unneeded rcu_process_callbacks() declarations rcu: Add long-term CPU kicking rcu: Remove short-term CPU kicking rcu: Once again use NMI-based stack traces in stall warnings rcu: Re-enable TASKS_RCU for User Mode Linux rcu: Don't wake rcuc/X kthreads on NOCB CPUs rcu: Add comment headers to expedited-grace-period counter functions rcu: Make rcu_cpu_starting() use its "cpu" argument rcu: Fix comment in rcu_organize_nocb_kthreads() rcu: Eliminate unused expedited_normal counter rcu: Add lockdep checks to synchronous expedited primitives rcu: Abstract dynticks extended quiescent state enter/exit operations rcu: Abstract extended quiescent state determination rcu: Check cond_resched_rcu_qs() state less often to reduce GP overhead rcu: Adjust FQS offline checks for exact online-CPU detection srcu: Force full grace-period ordering srcu: Reduce probability of SRCU ->unlock_count[] counter overflow Merge branches 'doc.2017.01.15b', 'dyntick.2017.01.23a', 'fixes.2017.01.23a', 'srcu.2017.01.25a' and 'torture.2017.01.15b' into HEAD Sebastian Andrzej Siewior (1): rcu: update: Make RCU_EXPEDITE_BOOT be the default Tetsuo Handa (1): doc: Fix RCU requirements typos Tobias Klauser (1): rcu: Remove unused but set variable Yang Shi (1): locktorture: Fix potential memory leak with rw lock test .../Design/Data-Structures/Data-Structures.html| 5 +- .../Design/Expedited-Grace-Periods/ExpRCUFlow.svg | 830 + .../Expedited-Grace-Periods/ExpSchedFlow.svg | 826 .../Expedited-Grace-Periods.html | 626 .../RCU/Design/Expedited-Grace-Periods/Funnel0.svg | 275 +++ .../RCU/Design/Expedited-Grace-Periods/Funnel1.svg | 275 +++ .../RCU/Design/Expedited-Grace-Periods/Funnel2.svg | 287 +++ .../RCU/Design/Expedited-Grace-Periods/Funnel3.svg | 323 .../RCU/Design/Expedited-Grace-Periods/Funnel4.svg | 323 .../RCU/Design/Expedited-Grace-Periods/Funnel5.svg | 335 + .../RCU/Design/Expedited-Grace-Periods/Funnel6.svg | 335 + .../RCU/Design/Expedited-Grace-Periods/Funnel7.svg | 347 + .../RCU/Design/Expedited-Grace-Periods/Funnel8.svg | 311 .../RCU/Design/Requirements/Re
Re: linux-next: manual merge of the gpio tree with the staging tree
On Mon, Jan 30, 2017 at 5:28 AM, Stephen Rothwell wrote: > 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. OK I'll mention it to Linus (the big penguin). Thanks! Linus Walleij
Re: [PATCH 11/22] ARM: dts: add top-level DT bindings for Cortina Gemini
On Sat, Jan 28, 2017 at 3:56 PM, Linus Walleij wrote:
> On Mon, Jan 23, 2017 at 9:21 PM, Rob Herring wrote:
>> On Sun, Jan 22, 2017 at 01:22:19PM +0100, Linus Walleij wrote:
>>> This adds the top level SoC bindings for Cortina systems Gemini
>>> platforms.
> (...)
>>> +- intcon: the root node must have an interrupt controller node pointing to
>>
>> intcon is just a source label and not meaningful for the binding.
>
> OK
>
>>> +Example:
>>> +
>>> +/ {
>>> + interrupt-parent = <&intcon>;
>>> +
>>> + syscon: syscon@4000 {
>>
>> This chip has no internal bus? Put all these nodes under a bus.
>
> Are you thinking something of the form:
>
> soc: soc {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
> compatible = "simple-bus";
>
> syscon: syscon@4000 {
>
> (...)
>
> ?
Yes.
Rob
Re: [PATCH RESEND] staging: media: lirc: use new parport device model
On Sat, Jan 21, 2017 at 12:55:54AM +, Sudip Mukherjee wrote: > From: Sudip Mukherjee > > Modify lirc_parallel driver to use the new parallel port device model. > > Signed-off-by: Sudip Mukherjee > --- > > Resending after more than one year. > Prevoius patch is at https://patchwork.kernel.org/patch/7883591/ Since noone ported lirc_parallel to rc-core, the lirc_parallel staging driver has been droppped from the current media tree. I have ported a few other lirc drivers to rc-core but I never found anyone using lirc_parallel or the hardware itself. Sean
Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process
On 01/29/2017 07:35 PM, Anshuman Khandual wrote:
> * CDM node's zones are not part of any other node's FALLBACK zonelist
> * CDM node's FALLBACK list contains it's own memory zones followed by
> all system RAM zones in regular order as before
> * CDM node's zones are part of it's own NOFALLBACK zonelist
This seems like a sane policy for the system that you're describing.
But, it's still a policy, and it's rather hard-coded into the kernel.
Let's say we had a CDM node with 100x more RAM than the rest of the
system and it was just as fast as the rest of the RAM. Would we still
want it isolated like this? Or would we want a different policy?
Why do we need this hard-coded along with the cpuset stuff later in the
series. Doesn't taking a node out of the cpuset also take it out of the
fallback lists?
> while ((node = find_next_best_node(local_node, &used_mask)) >= 0) {
> +#ifdef CONFIG_COHERENT_DEVICE
> + /*
> + * CDM node's own zones should not be part of any other
> + * node's fallback zonelist but only it's own fallback
> + * zonelist.
> + */
> + if (is_cdm_node(node) && (pgdat->node_id != node))
> + continue;
> +#endif
On a superficial note: Isn't that #ifdef unnecessary? is_cdm_node() has
a 'return 0' stub when the config option is off anyway.
Re: [PATCH RT] Align rt_mutex inlining with upstream behavior
On Thu, Jan 26, 2017 at 06:01:09PM +0100, Sebastian Andrzej Siewior wrote: > On 2017-01-24 18:45:50 [-0800], Alex Goins wrote: > > mutex_destroy is no-op inline when DEBUG_MUTEX is not enabled. The RT Linux > > patches replace mutex_destroy() with rt_mutex_destroy(). This patch aligns > > rt_mutex_destroy() with mutex_destroy() by using the same no-op inline > > technique. > > > > Signed-off-by: Alex Goins > > Reviewed-by: Andy Ritger > > So what is the problem? Why are we doing this? There is still a check to > see if the lock is in use which is also done for the case where > DEBUG_MUTEX is disabled. The problem is that various static inline functions such as reservation_object_fini() indirectly call mutex_destroy. On DEBUG_MUTEX kernels, mutex_destroy is EXPORT_SYMBOL_GPL. In upstream, non-DEBUG_MUTEX kernels define mutex_destroy to a noop. This gives users the option of disabling DEBUG_MUTEX if they want to use non-GPL, reservation_object_fini()-using, kernel modules. In PREEMPTRT, non-DEBUG_MUTEX kernels export rt_mutex_destroy as EXPORT_SYMBOL_GPL, so users no longer have the work around of using DEBUG_MUTEX. This patch gives PREEMPTRT users the option of disabling DEBUG_MUTEX if they want to use such kernel modules, matching upstream behavior.
Re: [RFC v2 10/10] KVM: arm/arm64: Emulate the EL1 phys timer register access
Hi Peter, On Mon, Jan 30, 2017 at 12:26 PM, Peter Maydell wrote: > On 30 January 2017 at 17:08, Jintack Lim wrote: >> On Sun, Jan 29, 2017 at 10:44 AM, Marc Zyngier wrote: >>> Shouldn't we take the ENABLE bit into account? The ARMv8 ARM version I >>> have at hand (version h) seems to indicate that we should, but we should >>> check with the latest and greatest... >> >> Thanks! I was not clear about this. I have ARM ARM version k, and it >> says that 'When the value of the ENABLE bit is 0, the ISTATUS field is >> UNKNOWN.' So I thought the istatus value doesn't matter if ENABLE is >> 0, and just set istatus bit regardless of ENABLE bit. If this is not >> what the manual meant, then I'm happy to fix this. > > It looks like the spec has been relaxed between the doc version > that Marc was looking at and the current one. So it's OK for > an implementation to either (a) set ISTATUS to 0 if ENABLE > is 0, or (b) do what you've done and set ISTATUS according > to the timer comparison whether ENABLE is clear or not > (or even (c) set ISTATUS to a random value if ENABLE is clear, > and other less likely choices). > I think we should add a comment to note that it's architecturally > UNKNOWN and we've made a choice for our implementation convenience. Thanks for the clarification. I'll put a comment in v3. > > thanks > -- PMM >
Re: [PATCH 2/2] x86/fpu: copy MXCSR & MXCSR_FLAGS with SSE/YMM state
On Wed, Jan 25, 2017 at 08:57:59PM -0500, r...@redhat.com wrote:
> From: Rik van Riel
>
> On Skylake CPUs I noticed that XRSTOR is unable to deal with states
> created by copyout_from_xsaves if the xstate has only SSE/YMM state, and
> no FP state. That is, xfeatures had XFEATURE_MASK_SSE set, but not
> XFEATURE_MASK_FP.
>
> The reason is that part of the SSE/YMM state lives in the MXCSR and
> MXCSR_FLAGS fields of the FP state.
>
> Ensure that whenever we copy SSE or YMM state around, the MXCSR and
> MXCSR_FLAGS fields are also copied around.
>
> Signed-off-by: Rik van Riel
> ---
> arch/x86/kernel/fpu/xstate.c | 39 ++-
> 1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index c1508d56ecfb..10b10917af81 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -1004,6 +1004,23 @@ int copyout_from_xsaves(unsigned int pos, unsigned int
> count, void *kbuf,
> }
>
> /*
> + * Restoring SSE/YMM state requires that MXCSR & MXCSR_MASK are saved.
> + * Those fields are part of the legacy FP state, and only get saved
> + * above if XFEATURES_MASK_FP is set.
> + *
> + * Copy out those fields if we have SSE/YMM but no FP register data.
> + */
> + if ((header.xfeatures & (XFEATURE_MASK_SSE|XFEATURE_MASK_YMM)) &&
> + !(header.xfeatures & XFEATURE_MASK_FP)) {
> + size = sizeof(u64);
> + ret = xstate_copyout(offset, size, kbuf, ubuf,
> + &xsave->i387.mxcsr, 0, count);
> +
> + if (ret)
> + return ret;
> + }
> +
> + /*
>* Fill xsave->i387.sw_reserved value for ptrace frame:
>*/
> offset = offsetof(struct fxregs_state, sw_reserved);
> @@ -1030,6 +1047,7 @@ int copyin_to_xsaves(const void *kbuf, const void
> __user *ubuf,
> int i;
> u64 xfeatures;
> u64 allowed_features;
> + void *dst;
>
> offset = offsetof(struct xregs_state, header);
> size = sizeof(xfeatures);
> @@ -1053,7 +1071,7 @@ int copyin_to_xsaves(const void *kbuf, const void
> __user *ubuf,
> u64 mask = ((u64)1 << i);
>
> if (xfeatures & mask) {
> - void *dst = __raw_xsave_addr(xsave, 1 << i);
> + dst = __raw_xsave_addr(xsave, 1 << i);
>
> offset = xstate_offsets[i];
> size = xstate_sizes[i];
> @@ -1068,6 +1086,25 @@ int copyin_to_xsaves(const void *kbuf, const void
> __user *ubuf,
> }
>
> /*
> + * SSE/YMM state depends on the MXCSR & MXCSR_MASK fields from the FP
> + * state. If we restored only SSE/YMM state but not FP state, copy
> + * those fields to ensure the SSE/YMM state restore works.
> + */
In xstateregs_set(), we enforced the starting pos must be from (0), which in
XSAVE time, was probably for this reason. The real mistake here, I think, is
allowing skipping of xstate[0] and xstate[1]. Both should have been there
even for XSAVES compacted-format. Would it be a simpler fix just making sure
xstate[0] and xstate[1] are copied?
Yu-cheng
Re: [PATCH V2] ARM: dts: BCM5301X: Add missing Netgear R8000 LEDs and Keys
On 01/30/2017 01:08 AM, Aditya Xavier wrote:
> Would you require me to send the revised Patch ?
>
> Or would this do ?
Will take care of it this time.
>
> And thanks for guiding me through this process :)
>
>
>> On 29-Jan-2017, at 2:45 AM, Rafał Miłecki wrote:
>>
>> On 28 January 2017 at 15:37, AdityaXavier wrote:
>>> From: Aditya Xavier
>>>
>>> Added two WAN status LEDs and a GPIO Key for Brightness which were missing.
>>> V2: Updated subject, Power LED names, and WAN labels.
>>
>> Changelog (V2 ... part) should go into that /comments/ section (see below).
>> Florian: can you drop that line when applying this patch? Otherwise it
>> looks OK to me.
>>
>>
>>> Signed-off-by: Aditya Xavier
>>
>> Acked-by: Rafał Miłecki
>>
>> Thanks for the patch!
>>
>>
>>> ---
>>
>> Right here, below these 3 dashes is a place where you can add extra
>> comments (they won't go into log when doing "git am").
>>
>>> arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 22 --
>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
>>> b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
>>> index 92f8a72..90d4420 100644
>>> --- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
>>> +++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
>>> @@ -27,18 +27,30 @@
>>>leds {
>>>compatible = "gpio-leds";
>>>
>>> - power0 {
>>> + power-white {
>>>label = "bcm53xx:white:power";
>>>gpios = <&chipcommon 2 GPIO_ACTIVE_LOW>;
>>>linux,default-trigger = "default-on";
>>>};
>>>
>>> - power1 {
>>> + power-amber {
>>>label = "bcm53xx:amber:power";
>>>gpios = <&chipcommon 3 GPIO_ACTIVE_LOW>;
>>>linux,default-trigger = "default-off";
>>>};
>>>
>>> + wan-white {
>>> + label = "bcm53xx:white:wan";
>>> + gpios = <&chipcommon 8 GPIO_ACTIVE_LOW>;
>>> + linux,default-trigger = "default-on";
>>> + };
>>> +
>>> + wan-amber {
>>> + label = "bcm53xx:amber:wan";
>>> + gpios = <&chipcommon 9 GPIO_ACTIVE_HIGH>;
>>> + linux,default-trigger = "default-off";
>>> + };
>>> +
>>>5ghz-1 {
>>>label = "bcm53xx:white:5ghz-1";
>>>gpios = <&chipcommon 12 GPIO_ACTIVE_LOW>;
>>> @@ -104,6 +116,12 @@
>>>linux,code = ;
>>>gpios = <&chipcommon 6 GPIO_ACTIVE_LOW>;
>>>};
>>> +
>>> + brightness {
>>> + label = "Backlight";
>>> + linux,code = ;
>>> + gpios = <&chipcommon 19 GPIO_ACTIVE_LOW>;
>>> + };
>>>};
>>> };
>>>
>>> --
>>> 2.9.3
>>>
>>
>>
>>
>> --
>> Rafał
>
--
Florian
[PATCH] usb: typec: fix ptr_ret.cocci warnings
drivers/usb/typec/typec.c:1249:1-3: WARNING: PTR_ERR_OR_ZERO can be used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
CC: Heikki Krogerus
Signed-off-by: Fengguang Wu
---
typec.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/usb/typec/typec.c
+++ b/drivers/usb/typec/typec.c
@@ -1246,9 +1246,7 @@ EXPORT_SYMBOL_GPL(typec_unregister_port)
static int __init typec_init(void)
{
typec_class = class_create(THIS_MODULE, "typec");
- if (IS_ERR(typec_class))
- return PTR_ERR(typec_class);
- return 0;
+ return PTR_ERR_OR_ZERO(typec_class);
}
subsys_initcall(typec_init);
Re: [PATCH] printk: fix printk.devkmsg sysctl
On Fri, Jan 27, 2017 at 07:19:30PM +0100, Borislav Petkov wrote: > On Fri, Jan 27, 2017 at 04:42:30PM +0100, Rabin Vincent wrote: > > proc_dostring() eats the '\n' and stops > > Not a problem, see diff below. Would it be possible for you to please submit it as a patch yourself so that this gets fixed in the way you like? Thank you.
Re: [PATCH v16 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
Hi Heikki, [auto build test WARNING on usb/usb-testing] [also build test WARNING on v4.10-rc6 next-20170130] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Heikki-Krogerus/lib-string-add-sysfs_match_string-helper/20170130-214825 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing coccinelle warnings: (new ones prefixed by >>) >> drivers/usb/typec/typec.c:1249:1-3: WARNING: PTR_ERR_OR_ZERO can be used Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [RFC v2 02/10] KVM: arm/arm64: Move cntvoff to each timer context
On Mon, Jan 30, 2017 at 9:51 AM, Marc Zyngier wrote:
> On 30/01/17 14:45, Christoffer Dall wrote:
>> On Sun, Jan 29, 2017 at 11:54:05AM +, Marc Zyngier wrote:
>>> On Fri, Jan 27 2017 at 01:04:52 AM, Jintack Lim
>>> wrote:
Make cntvoff per each timer context. This is helpful to abstract kvm
timer functions to work with timer context without considering timer
types (e.g. physical timer or virtual timer).
This also would pave the way for ever doing adjustments of the cntvoff
on a per-CPU basis if that should ever make sense.
Signed-off-by: Jintack Lim
---
arch/arm/include/asm/kvm_host.h | 6 +++---
arch/arm64/include/asm/kvm_host.h | 4 ++--
include/kvm/arm_arch_timer.h | 8 +++-
virt/kvm/arm/arch_timer.c | 26 --
virt/kvm/arm/hyp/timer-sr.c | 3 +--
5 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h
b/arch/arm/include/asm/kvm_host.h
index d5423ab..f5456a9 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -60,9 +60,6 @@ struct kvm_arch {
/* The last vcpu id that ran on each physical CPU */
int __percpu *last_vcpu_ran;
- /* Timer */
- struct arch_timer_kvm timer;
-
/*
* Anything that is not used directly from assembly code goes
* here.
@@ -75,6 +72,9 @@ struct kvm_arch {
/* Stage-2 page table */
pgd_t *pgd;
+ /* A lock to synchronize cntvoff among all vtimer context of vcpus */
+ spinlock_t cntvoff_lock;
>>>
>>> Is there any condition where we need this to be a spinlock? I would have
>>> thought that a mutex should have been enough, as this should only be
>>> updated on migration or initialization. Not that it matters much in this
>>> case, but I wondered if there is something I'm missing.
>>>
>>
>> I would think the critical section is small enough that a spinlock makes
>> sense, but what I don't think we need is to add the additional lock.
>>
>> I think just taking the kvm->lock should be sufficient, which happens to
>> be a mutex, and while that may be a bit slower to take than the
>> spinlock, it's not in the critical path so let's just keep things
>> simple.
>>
>> Perhaps this what Marc also meant.
>
> That would be the logical conclusion, assuming that we can sleep on this
> path.
All right. I'll take kvm->lock there.
Thanks,
Jintack
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
>
[PATCH 2/2] iommu/vt-d: tylersburg isoch identity map check is done too late.
The check to set identity map for tylersburg is done too late. It needs
to be done before the check for identity_map domain is done.
To: Joerg Roedel
To: David Woodhouse
Cc: io...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: Ashok Raj
Fixes: 86080ccc22 ("iommu/vt-d: Allocate si_domain in init_dmars()")
Signed-off-by: Ashok Raj
Reported-by: Yunhong Jiang
---
drivers/iommu/intel-iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 8a18525..23eead3 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3325,13 +3325,14 @@ static int __init init_dmars(void)
iommu_identity_mapping |= IDENTMAP_GFX;
#endif
+ check_tylersburg_isoch();
+
if (iommu_identity_mapping) {
ret = si_domain_init(hw_pass_through);
if (ret)
goto free_iommu;
}
- check_tylersburg_isoch();
/*
* If we copied translations from a previous kernel in the kdump
--
2.7.4
[PATCH 1/2] iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu
From: CQ Tang
Some of the macros are incorrect with wrong bit-shifts resulting in picking
the incorrect invalidation granularity. Incorrect Source-ID in extended
devtlb invalidation caused device side errors.
To: Joerg Roedel
To: David Woodhouse
Cc: io...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org
Cc: CQ Tang
Cc: Ashok Raj
Fixes: 2f26e0a9 ("iommu/vt-d: Add basic SVM PASID support")
Signed-off-by: CQ Tang
Signed-off-by: Ashok Raj
Tested-by: CQ Tang
---
include/linux/intel-iommu.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index d49e26c..23e129e 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -153,8 +153,8 @@ static inline void dmar_writeq(void __iomem *addr, u64 val)
#define DMA_TLB_GLOBAL_FLUSH (((u64)1) << 60)
#define DMA_TLB_DSI_FLUSH (((u64)2) << 60)
#define DMA_TLB_PSI_FLUSH (((u64)3) << 60)
-#define DMA_TLB_IIRG(type) ((type >> 60) & 7)
-#define DMA_TLB_IAIG(val) (((val) >> 57) & 7)
+#define DMA_TLB_IIRG(type) ((type >> 60) & 3)
+#define DMA_TLB_IAIG(val) (((val) >> 57) & 3)
#define DMA_TLB_READ_DRAIN (((u64)1) << 49)
#define DMA_TLB_WRITE_DRAIN (((u64)1) << 48)
#define DMA_TLB_DID(id)(((u64)((id) & 0x)) << 32)
@@ -164,9 +164,9 @@ static inline void dmar_writeq(void __iomem *addr, u64 val)
/* INVALID_DESC */
#define DMA_CCMD_INVL_GRANU_OFFSET 61
-#define DMA_ID_TLB_GLOBAL_FLUSH(((u64)1) << 3)
-#define DMA_ID_TLB_DSI_FLUSH (((u64)2) << 3)
-#define DMA_ID_TLB_PSI_FLUSH (((u64)3) << 3)
+#define DMA_ID_TLB_GLOBAL_FLUSH(((u64)1) << 4)
+#define DMA_ID_TLB_DSI_FLUSH (((u64)2) << 4)
+#define DMA_ID_TLB_PSI_FLUSH (((u64)3) << 4)
#define DMA_ID_TLB_READ_DRAIN (((u64)1) << 7)
#define DMA_ID_TLB_WRITE_DRAIN (((u64)1) << 6)
#define DMA_ID_TLB_DID(id) (((u64)((id & 0x) << 16)))
@@ -316,8 +316,8 @@ enum {
#define QI_DEV_EIOTLB_SIZE (((u64)1) << 11)
#define QI_DEV_EIOTLB_GLOB(g) ((u64)g)
#define QI_DEV_EIOTLB_PASID(p) (((u64)p) << 32)
-#define QI_DEV_EIOTLB_SID(sid) ((u64)((sid) & 0x) << 32)
-#define QI_DEV_EIOTLB_QDEP(qd) (((qd) & 0x1f) << 16)
+#define QI_DEV_EIOTLB_SID(sid) ((u64)((sid) & 0x) << 16)
+#define QI_DEV_EIOTLB_QDEP(qd) ((u64)((qd) & 0x1f) << 4)
#define QI_DEV_EIOTLB_MAX_INVS 32
#define QI_PGRP_IDX(idx) (((u64)(idx)) << 55)
--
2.7.4
[RFC 0/3] Add system power and restart framework
From: Thierry Reding Hi everyone, This series of patches proposes a small framework targetted at system power and restart drivers. Restart drivers currently use a notifier chain and there was an attempt by Guenter Roeck a while ago to move power off drivers to similar infrastructure[0]. That attempt had met with some pushback, with the main criticism being that there was no formal definition of the priorities of these handlers. The system power and restart framework tries to solve this by adding a more explicit framework that power and restart drivers can register with. This is currently very simple, but it is meant primarily as a basis for discussion so that we can reach concensus on what we want such a framework to look like (and if we need one at all). There was a bit of discussion on this two weeks ago[1], and this set is an attempt at implementing my proposal from that discussion[2]. A formal mechanism to implement priorities on top of this could easily be added (see linked discussion). One very big advantage of this method is that we have a very easy way of keeping backwards compatibility with the restart notifier chain and the pm_power_off() mechanism, which means we can convert drivers one by one and evolve the framework incrementally without having to have a flag day where everyone needs to convert. So the goal of this series is to get some feedback on whether or not the people involved in earlier discussions around this think this is sound. If so I've got a couple of patches on top that convert architectures over to using the new function calls and a couple of drivers that I have converted as a proof of concept. Thanks, Thierry [0]: https://lkml.org/lkml/2014/11/6/505 [1]: https://lkml.org/lkml/2017/1/12/470 [2]: https://lkml.org/lkml/2017/1/20/89 Thierry Reding (3): system-power: Add system power and restart framework kernel: Wire up system power framework PM / hibernate: Wire up system-power framework drivers/base/Makefile| 3 +- drivers/base/system-power.c | 110 +++ include/linux/system-power.h | 38 +++ kernel/power/hibernate.c | 3 +- kernel/reboot.c | 11 +++-- 5 files changed, 158 insertions(+), 7 deletions(-) create mode 100644 drivers/base/system-power.c create mode 100644 include/linux/system-power.h -- 2.11.0
Re: [RFC v2 10/10] KVM: arm/arm64: Emulate the EL1 phys timer register access
On 30/01/17 17:26, Peter Maydell wrote: > On 30 January 2017 at 17:08, Jintack Lim wrote: >> On Sun, Jan 29, 2017 at 10:44 AM, Marc Zyngier wrote: >>> Shouldn't we take the ENABLE bit into account? The ARMv8 ARM version I >>> have at hand (version h) seems to indicate that we should, but we should >>> check with the latest and greatest... >> >> Thanks! I was not clear about this. I have ARM ARM version k, and it >> says that 'When the value of the ENABLE bit is 0, the ISTATUS field is >> UNKNOWN.' So I thought the istatus value doesn't matter if ENABLE is >> 0, and just set istatus bit regardless of ENABLE bit. If this is not >> what the manual meant, then I'm happy to fix this. > > It looks like the spec has been relaxed between the doc version > that Marc was looking at and the current one. So it's OK for > an implementation to either (a) set ISTATUS to 0 if ENABLE > is 0, or (b) do what you've done and set ISTATUS according > to the timer comparison whether ENABLE is clear or not > (or even (c) set ISTATUS to a random value if ENABLE is clear, > and other less likely choices). > I think we should add a comment to note that it's architecturally > UNKNOWN and we've made a choice for our implementation convenience. In that case, the proposed implementation is perfectly fine. I'll retire the old ARMv8 ARM from my laptop (funnily enough, I didn't fancy downloading version k while on the train and having my phone as my link to the outside world... ;-). Thanks, M. -- Jazz is not dead. It just smells funny...
Re: [PATCH] i2c: at91: ensure state is restored after suspending
> + at91_init_twi_bus(twi_dev); Can't this function reinit the registers to the needed values? I am not convinced that a cache will always reflect the proper state after resume. signature.asc Description: PGP signature
Re: [RFC v2 05/10] KVM: arm/arm64: Initialize the emulated EL1 physical timer
On 30/01/17 14:58, Christoffer Dall wrote:
> On Sun, Jan 29, 2017 at 12:07:48PM +, Marc Zyngier wrote:
>> On Fri, Jan 27 2017 at 01:04:55 AM, Jintack Lim
>> wrote:
>>> Initialize the emulated EL1 physical timer with the default irq number.
>>>
>>> Signed-off-by: Jintack Lim
>>> ---
>>> arch/arm/kvm/reset.c | 9 -
>>> arch/arm64/kvm/reset.c | 9 -
>>> include/kvm/arm_arch_timer.h | 3 ++-
>>> virt/kvm/arm/arch_timer.c| 9 +++--
>>> 4 files changed, 25 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
>>> index 4b5e802..1da8b2d 100644
>>> --- a/arch/arm/kvm/reset.c
>>> +++ b/arch/arm/kvm/reset.c
>>> @@ -37,6 +37,11 @@
>>> .usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
>>> };
>>>
>>> +static const struct kvm_irq_level cortexa_ptimer_irq = {
>>> + { .irq = 30 },
>>> + .level = 1,
>>> +};
>>
>> At some point, we'll have to make that discoverable/configurable. Maybe
>> the time for a discoverable arch timer has come (see below).
>>
>>> +
>>> static const struct kvm_irq_level cortexa_vtimer_irq = {
>>> { .irq = 27 },
>>> .level = 1,
>>> @@ -58,6 +63,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>> {
>>> struct kvm_regs *reset_regs;
>>> const struct kvm_irq_level *cpu_vtimer_irq;
>>> + const struct kvm_irq_level *cpu_ptimer_irq;
>>>
>>> switch (vcpu->arch.target) {
>>> case KVM_ARM_TARGET_CORTEX_A7:
>>> @@ -65,6 +71,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>> reset_regs = &cortexa_regs_reset;
>>> vcpu->arch.midr = read_cpuid_id();
>>> cpu_vtimer_irq = &cortexa_vtimer_irq;
>>> + cpu_ptimer_irq = &cortexa_ptimer_irq;
>>> break;
>>> default:
>>> return -ENODEV;
>>> @@ -77,5 +84,5 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>> kvm_reset_coprocs(vcpu);
>>>
>>> /* Reset arch_timer context */
>>> - return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
>>> + return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq, cpu_ptimer_irq);
>>> }
>>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>>> index e95d4f6..d9e9697 100644
>>> --- a/arch/arm64/kvm/reset.c
>>> +++ b/arch/arm64/kvm/reset.c
>>> @@ -46,6 +46,11 @@
>>> COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
>>> };
>>>
>>> +static const struct kvm_irq_level default_ptimer_irq = {
>>> + .irq= 30,
>>> + .level = 1,
>>> +};
>>> +
>>> static const struct kvm_irq_level default_vtimer_irq = {
>>> .irq= 27,
>>> .level = 1,
>>> @@ -104,6 +109,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm,
>>> long ext)
>>> int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>> {
>>> const struct kvm_irq_level *cpu_vtimer_irq;
>>> + const struct kvm_irq_level *cpu_ptimer_irq;
>>> const struct kvm_regs *cpu_reset;
>>>
>>> switch (vcpu->arch.target) {
>>> @@ -117,6 +123,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>> }
>>>
>>> cpu_vtimer_irq = &default_vtimer_irq;
>>> + cpu_ptimer_irq = &default_ptimer_irq;
>>> break;
>>> }
>>>
>>> @@ -130,5 +137,5 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>>> kvm_pmu_vcpu_reset(vcpu);
>>>
>>> /* Reset timer */
>>> - return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
>>> + return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq, cpu_ptimer_irq);
>>> }
>>> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
>>> index 69f648b..a364593 100644
>>> --- a/include/kvm/arm_arch_timer.h
>>> +++ b/include/kvm/arm_arch_timer.h
>>> @@ -59,7 +59,8 @@ struct arch_timer_cpu {
>>> int kvm_timer_enable(struct kvm_vcpu *vcpu);
>>> void kvm_timer_init(struct kvm *kvm);
>>> int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>>> -const struct kvm_irq_level *irq);
>>> +const struct kvm_irq_level *virt_irq,
>>> +const struct kvm_irq_level *phys_irq);
>>> void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
>>> void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
>>> void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>>> index f72005a..0f6e935 100644
>>> --- a/virt/kvm/arm/arch_timer.c
>>> +++ b/virt/kvm/arm/arch_timer.c
>>> @@ -329,9 +329,11 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
>>> }
>>>
>>> int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>>> -const struct kvm_irq_level *irq)
>>> +const struct kvm_irq_level *virt_irq,
>>> +const struct kvm_irq_level *phys_irq)
>>> {
>>> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>>> + struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
>>>
>>> /*
>>> * The vcpu timer irq number cannot be determined in
>>> @@ -339,7 +341,8 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>>> * kvm_vcpu_set_target(). To handle th
Re: [PATCH] perf/x86/intel/rapl: Rename rapl_cpu_prepare() to rapl_cpu_starting()
On 01/30/2017 11:56 AM, Thomas Gleixner wrote: On Mon, 30 Jan 2017, Yasuaki Ishimatsu wrote: Hi Thomas, Do you have any idea to fix the issue? If you have the idea, please send me the patch. Yes, I have a patch, but need to do some tests and get changelogs written. Will keep you updated. Great!! I wait for your patch. Thanks, Yasuaki Ishimatsu Thanks, tglx
Re: [PATCH] Staging: omap4iss: fix coding style issues
Hello Avraham,
Thank you for the patch.
On Saturday 28 Jan 2017 20:00:08 Avraham Shukron wrote:
> This is a patch that fixes checkpatch.pl issues in omap4iss/iss_video.c
> Specifically, it fixes "line over 80 characters" issues
>
> Signed-off-by: Avraham Shukron
This looks OK to me. I've applied the patch to my tree and will push it to
v4.11.
Acked-by: Laurent Pinchart
> ---
> drivers/staging/media/omap4iss/iss_video.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/media/omap4iss/iss_video.c
> b/drivers/staging/media/omap4iss/iss_video.c index c16927a..cdab053 100644
> --- a/drivers/staging/media/omap4iss/iss_video.c
> +++ b/drivers/staging/media/omap4iss/iss_video.c
> @@ -298,7 +298,8 @@ iss_video_check_format(struct iss_video *video, struct
> iss_video_fh *vfh)
>
> static int iss_video_queue_setup(struct vb2_queue *vq,
>unsigned int *count, unsigned int
*num_planes,
> - unsigned int sizes[], struct device
*alloc_devs[])
> + unsigned int sizes[],
> + struct device *alloc_devs[])
> {
> struct iss_video_fh *vfh = vb2_get_drv_priv(vq);
> struct iss_video *video = vfh->video;
> @@ -678,8 +679,8 @@ iss_video_get_selection(struct file *file, void *fh,
> struct v4l2_selection *sel) if (subdev == NULL)
> return -EINVAL;
>
> - /* Try the get selection operation first and fallback to get format if
not
> - * implemented.
> + /* Try the get selection operation first and fallback to get format if
> + * not implemented.
>*/
> sdsel.pad = pad;
> ret = v4l2_subdev_call(subdev, pad, get_selection, NULL, &sdsel);
--
Regards,
Laurent Pinchart
Re: [PATCH RESEND 2/5] dmaengine: Provide a wrapper for memcpy operations
Hi Vinod, On Mon, 30 Jan 2017 22:24:17 +0530 Vinod Koul wrote: > On Fri, Jan 27, 2017 at 05:42:01PM +0100, Boris Brezillon wrote: > > Almost all ->device_prep_dma_xx() methods have a wrapper defined in > > dmaengine.h. Add one for ->device_prep_dma_memcpy(). > > Looks good to me. > > Acked-by: Vinod Koul > > Maybe you can take this patch directly (the NAND related bits are for 4.12).
Re: [PATCH v6 5/5] Documentation:powerpc: Add device-tree bindings for power-mgt
On Wed, Jan 25, 2017 at 02:06:29PM +0530, Gautham R. Shenoy wrote: > From: "Gautham R. Shenoy" > > Document the device-tree bindings defining the the properties under > the @power-mgt node in the device tree that describe the idle states > for Linux running on baremetal POWER servers. > > These bindings are documented separately instead of using the the > common idle state bindings since the idle-states on POWER servers > are exposed as property arrays where as the common idle state bindings > expect idle-states to be described as nodes. > > Cc: Rob Herring > Signed-off-by: Gautham R. Shenoy > --- > .../devicetree/bindings/powerpc/opal/power-mgt.txt | 118 > + > 1 file changed, 118 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt Acked-by: Rob Herring
Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
* Pavel Machek [170127 11:41]: > On Fri 2017-01-27 17:23:07, Kalle Valo wrote: > > Pali Rohár writes: > > > > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote: > > >> Pali Rohár writes: > > >> > > >> > 2) It was already tested that example NVS data can be used for N900 > > >> > e.g. > > >> > for SSH connection. If real correct data are not available it is better > > >> > to use at least those example (and probably log warning message) so > > >> > user > > >> > can connect via SSH and start investigating where is problem. > > >> > > >> I disagree. Allowing default calibration data to be used can be > > >> unnoticed by user and left her wondering why wifi works so badly. > > > > > > So there are only two options: > > > > > > 1) Disallow it and so these users will have non-working wifi. > > > > > > 2) Allow those data to be used as fallback mechanism. > > > > > > And personally I'm against 1) because it will break wifi support for > > > *all* Nokia N900 devices right now. > > > > All two of them? :) > > Umm. You clearly want a flock of angry penguins at your doorsteps :-). Well this silly issue of symlinking and renaming nvs files in a standard Linux distro was also hitting me on various devices with wl12xx/wl18xx trying to use the same rootfs. Why don't we just set a custom compatible property for n900 that then picks up some other nvs file instead of the default? Regards, Tony
Re: [PATCH] printk: fix printk.devkmsg sysctl
On Mon, Jan 30, 2017 at 06:31:38PM +0100, Rabin Vincent wrote: > Would it be possible for you to please submit it as a patch yourself so > that this gets fixed in the way you like? Thank you. Sure. I'll add your Reported-by when we're done. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: [RFC V2 12/12] mm: Tag VMA with VM_CDM flag explicitly during mbind(MPOL_BIND)
On 01/29/2017 07:35 PM, Anshuman Khandual wrote: > + if ((new_pol->mode == MPOL_BIND) > + && nodemask_has_cdm(new_pol->v.nodes)) > + set_vm_cdm(vma); So, if you did: mbind(addr, PAGE_SIZE, MPOL_BIND, all_nodes, ...); mbind(addr, PAGE_SIZE, MPOL_BIND, one_non_cdm_node, ...); You end up with a VMA that can never have KSM done on it, etc... Even though there's no good reason for it. I guess /proc/$pid/smaps might be able to help us figure out what was going on here, but that still seems like an awful lot of damage.
Re: irq domain hierarchy vs. chaining w/ PCI MSI-X...
On 01/30/2017 05:32 AM, Thomas Gleixner wrote: On Fri, 13 Jan 2017, David Daney wrote: At the point where the handle_*_irq() functions call handle_irq_event(), we need to 9optionally) do something both immediately before and after the call to handle_irq_event(). In irq_chip add a function: void (*irq_handle)(struct irq_data *data, struct irq_desc *desc); Really this is the per irq_chip flow handler. Then in handle_fasteoi_irq() and probably the other flow handlers as well: . . . if (chip->irq_handle) chip->irq_handle(&desc->irq_data, desc); else handle_irq_event(desc); . . . Those 4 lines of code could be factored out into a helper function in chip.c And why don't you just write a flow handler function which does exactly what you need instead of adding more conditionals into all hotpath functions? I came to the same conclusion myself and have already started to implement it that way. In my particular use case, we already know for certain which flow handler the parent irqdomain is using, so it is easy to copy it and add the extra handling needed by the child irq_chip. In the general case, a driver cannot know which flow handler the parent irqdomain is using, so it is impossible to know how to write a new flow handler that implements the desired semantics of the irq_chip hierarchy. David Daney
Re: [PATCH 0/7] Fix issues and factorize arm/arm64 capacity information code
On Mon, Jan 30, 2017 at 12:29:01PM +, Juri Lelli wrote: > I'd need more advice on this set, especially on how and if patch 6 could fly. Since you got some comments and said that you are going to fix them in the next version, I guess people are waiting for you to post a new series. -- Catalin
[RFC 1/3] system-power: Add system power and restart framework
From: Thierry Reding
This adds a very simple framework that allows drivers to register system
power and restart controllers. The goal of this framework is to replace
the current notifier based mechanism for restart handlers and the power
off equivalent that is the global pm_power_off() function.
Both of these approaches currently lack any means of locking against
concurrently registering handlers or formal definitions on what proper
priorities are to order handlers.
The system-power framework attempts to remedy this by adding a system
power chip object that drivers can embed in their driver-specific data.
A chip contains a description of capabilities that the framework uses
to determine a good sequence of handlers to use for restart and power
off.
Signed-off-by: Thierry Reding
---
drivers/base/Makefile| 3 +-
drivers/base/system-power.c | 110 +++
include/linux/system-power.h | 38 +++
3 files changed, 150 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/system-power.c
create mode 100644 include/linux/system-power.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index f2816f6ff76a..eef165221d9d 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,7 +4,8 @@ obj-y := component.o core.o bus.o dd.o
syscore.o \
driver.o class.o platform.o \
cpu.o firmware.o init.o map.o devres.o \
attribute_container.o transport_class.o \
- topology.o container.o property.o cacheinfo.o
+ topology.o container.o property.o cacheinfo.o \
+ system-power.o
obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
obj-y += power/
diff --git a/drivers/base/system-power.c b/drivers/base/system-power.c
new file mode 100644
index ..96c0cb457933
--- /dev/null
+++ b/drivers/base/system-power.c
@@ -0,0 +1,110 @@
+/*
+ * Copyright (c) 2017 NVIDIA Corporation
+ *
+ * This file is released under the GPL v2
+ */
+
+#define pr_fmt(fmt) "system-power: " fmt
+
+#include
+
+static DEFINE_MUTEX(system_power_lock);
+static LIST_HEAD(system_power_chips);
+
+int system_power_chip_add(struct system_power_chip *chip)
+{
+ if (!chip->ops || (!chip->ops->restart && !chip->ops->power_off)) {
+ WARN(1, pr_fmt("must implement restart or power off\n"));
+ return -EINVAL;
+ }
+
+ mutex_lock(&system_power_lock);
+
+ INIT_LIST_HEAD(&chip->list);
+ list_add_tail(&chip->list, &system_power_chips);
+
+ mutex_unlock(&system_power_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(system_power_chip_add);
+
+int system_power_chip_remove(struct system_power_chip *chip)
+{
+ mutex_lock(&system_power_lock);
+
+ list_del_init(&chip->list);
+
+ mutex_unlock(&system_power_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(system_power_chip_remove);
+
+bool system_can_power_off(void)
+{
+ /* XXX for backwards compatibility */
+ return pm_power_off != NULL;
+}
+
+int system_restart(char *cmd)
+{
+ struct system_power_chip *chip;
+ int err;
+
+ mutex_lock(&system_power_lock);
+
+ list_for_each_entry(chip, &system_power_chips, list) {
+ if (!chip->ops->restart)
+ continue;
+
+ pr_debug("trying to restart using %ps\n", chip);
+
+ err = chip->ops->restart(chip, reboot_mode, cmd);
+ if (err < 0)
+ dev_warn(chip->dev, "failed to restart: %d\n", err);
+ }
+
+ mutex_unlock(&system_power_lock);
+
+ /* XXX for backwards compatibility */
+ do_kernel_restart(cmd);
+
+ return 0;
+}
+
+int system_power_off_prepare(void)
+{
+ /* XXX for backwards compatibility */
+ if (pm_power_off_prepare)
+ pm_power_off_prepare();
+
+ return 0;
+}
+
+int system_power_off(void)
+{
+ struct system_power_chip *chip;
+ int err;
+
+ mutex_lock(&system_power_lock);
+
+ list_for_each_entry(chip, &system_power_chips, list) {
+ if (!chip->ops->power_off)
+ continue;
+
+ pr_debug("trying to power off using %ps\n", chip);
+
+ err = chip->ops->power_off(chip);
+ if (err < 0)
+ dev_warn(chip->dev, "failed to power off: %d\n", err);
+ }
+
+ mutex_unlock(&system_power_lock);
+
+ /* XXX for backwards compatibility */
+ if (pm_power_off)
+ pm_power_off();
+
+ return 0;
+}
diff --git a/include/linux/system-power.h b/include/linux/system-power.h
new file mode 100644
index ..f709c14c1552
--- /dev/null
+++ b/include/linux/system-power.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2017 NVIDIA Corporation
+ *
+ * This file is released under the GPL v
[PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()
rx_refill_timer should be deleted as soon as we disconnect from the
backend since otherwise it is possible for the timer to go off before
we get to xennet_destroy_queues(). If this happens we may dereference
queue->rx.sring which is set to NULL in xennet_disconnect_backend().
Signed-off-by: Boris Ostrovsky
CC: sta...@vger.kernel.org
---
drivers/net/xen-netfront.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 8315fe7..722fe9f 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1379,6 +1379,8 @@ static void xennet_disconnect_backend(struct
netfront_info *info)
for (i = 0; i < num_queues && info->queues; ++i) {
struct netfront_queue *queue = &info->queues[i];
+ del_timer_sync(&queue->rx_refill_timer);
+
if (queue->tx_irq && (queue->tx_irq == queue->rx_irq))
unbind_from_irqhandler(queue->tx_irq, queue);
if (queue->tx_irq && (queue->tx_irq != queue->rx_irq)) {
@@ -1733,7 +1735,6 @@ static void xennet_destroy_queues(struct netfront_info
*info)
if (netif_running(info->netdev))
napi_disable(&queue->napi);
- del_timer_sync(&queue->rx_refill_timer);
netif_napi_del(&queue->napi);
}
--
1.8.3.1
Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.
On Thu, Jan 26, 2017 at 01:49:03PM +0800, Fu Wei wrote:
> On 26 January 2017 at 01:25, Mark Rutland wrote:
> > On Wed, Jan 25, 2017 at 02:46:12PM +0800, Fu Wei wrote:
> >> On 25 January 2017 at 01:24, Mark Rutland wrote:
> >> > On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu@linaro.org wrote:
> >> >> From: Fu Wei
> > For CNT{,EL0}BaseN.CNTFRQ, I am very concerned by the wording in the
> > current ARMv8 ARM ARM. This does not match my understanding, nor does it
> > match the description in the ARMv7 ARM. I believe this may be a
> > documentation error, and I'm chasing that up internally.
> >
> > Either the currently logic in the driver which attempts to read
> > CNT{,EL0}BaseN.CNTFRQ is flawed, or the description in the ARM ARM is
> > erroneous.
>
> Yes, those description did confuse me. :-(
>
> But according to another document(ARMv8-A Foundation Platform User
> Guide ARM DUI0677K),
> Table 3-2 ARMv8-A Foundation Platform memory map (continued)
>
> AP_REFCLK CNTBase0, Generic Timer 64KB S
> AP_REFCLK CNTBase1, Generic Timer 64KB S/NS
>
> Dose it means the timer frame 0 can be accessed in SECURE status only,
> and the timer frame 1 can be accessed in both status?
That does appear to be what it says.
I assume in this case CNTCTLBase.CNTSAR<0> is RES0.
> And because Linux kernel is running on Non-secure EL1, so should we
> skip "SECURE" timer in Linux?
I guess you mean by checking the GTx Common flags, to see if the timer
is secure? Yes, we must skip those.
Looking further at this, the ACPI spec is sorely lacking any statement
as to the configuration of CNTCTLBase.{CNTSAR,CNTTIDR,CNTACR}, so it's
not clear if we can access anything in a frame, even if it is listed as
being a non-secure timer.
I think we need a stronger statement here. Otherwise, we will encounter
problems. Linux currently assumes that CNTCTLBase.CNTACR is
writeable, given a non-secure frame N. This is only the case if
CNTCTLBase.CNTSAR.NS == 1.
Thanks,
Mark.
[PATCH] powerpc: sort Kconfig selects under CONFIG_PPC
config PPC has a lot of selects under it. They're not sorted in any particular order, leading to merge conflicts when adding items at the end. Sort them alphabetically. Suggested-by: Michael Ellerman Signed-off-by: Andrew Donnellan --- On top of linux-next 20170130 --- arch/powerpc/Kconfig | 128 +-- 1 file changed, 64 insertions(+), 64 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 689cf9218b21..570195c8a86a 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -80,91 +80,91 @@ config ARCH_HAS_DMA_SET_COHERENT_MASK config PPC bool default y - select BUILDTIME_EXTABLE_SORT + select ARCH_HAS_DEVMEM_IS_ALLOWED + select ARCH_HAS_DMA_SET_COHERENT_MASK + select ARCH_HAS_ELF_RANDOMIZE + select ARCH_HAS_GCOV_PROFILE_ALL + select ARCH_HAS_SCALED_CPUTIME if VIRT_CPU_ACCOUNTING_NATIVE + select ARCH_HAS_SG_CHAIN + select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST + select ARCH_HAS_UBSAN_SANITIZE_ALL + select ARCH_HAVE_NMI_SAFE_CMPXCHG select ARCH_MIGHT_HAVE_PC_PARPORT select ARCH_MIGHT_HAVE_PC_SERIO + select ARCH_SUPPORTS_ATOMIC_RMW + select ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT + select ARCH_USE_BUILTIN_BSWAP + select ARCH_USE_CMPXCHG_LOCKREF if PPC64 + select ARCH_WANT_IPC_PARSE_VERSION + select ARCH_WEAK_RELEASE_ACQUIRE select BINFMT_ELF - select ARCH_HAS_ELF_RANDOMIZE - select OF - select OF_EARLY_FLATTREE - select OF_RESERVED_MEM - select HAVE_FTRACE_MCOUNT_RECORD + select BUILDTIME_EXTABLE_SORT + select CLONE_BACKWARDS + select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN + select EDAC_ATOMIC_SCRUB + select EDAC_SUPPORT + select GENERIC_ATOMIC64 if PPC32 + select GENERIC_CLOCKEVENTS + select GENERIC_CLOCKEVENTS_BROADCAST if SMP + select GENERIC_CMOS_UPDATE + select GENERIC_CPU_AUTOPROBE + select GENERIC_IRQ_SHOW + select GENERIC_IRQ_SHOW_LEVEL + select GENERIC_SMP_IDLE_THREAD + select GENERIC_STRNCPY_FROM_USER + select GENERIC_STRNLEN_USER + select GENERIC_TIME_VSYSCALL_OLD + select HAVE_ARCH_AUDITSYSCALL + select HAVE_ARCH_HARDENED_USERCOPY + select HAVE_ARCH_JUMP_LABEL + select HAVE_ARCH_KGDB + select HAVE_ARCH_SECCOMP_FILTER + select HAVE_ARCH_TRACEHOOK + select HAVE_CBPF_JIT if !PPC64 + select HAVE_DEBUG_KMEMLEAK + select HAVE_DEBUG_STACKOVERFLOW + select HAVE_DMA_API_DEBUG select HAVE_DYNAMIC_FTRACE select HAVE_DYNAMIC_FTRACE_WITH_REGS if MPROFILE_KERNEL - select HAVE_FUNCTION_TRACER + select HAVE_EBPF_JIT if PPC64 + select HAVE_EFFICIENT_UNALIGNED_ACCESS if !(CPU_LITTLE_ENDIAN && POWER7_CPU) + select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_GRAPH_TRACER - select SYSCTL_EXCEPTION_TRACE - select VIRT_TO_BUS if !PPC64 + select HAVE_FUNCTION_TRACER + select HAVE_GENERIC_RCU_GUP + select HAVE_HW_BREAKPOINT if PERF_EVENTS && (PPC_BOOK3S || PPC_8xx) select HAVE_IDE select HAVE_IOREMAP_PROT - select HAVE_EFFICIENT_UNALIGNED_ACCESS if !(CPU_LITTLE_ENDIAN && POWER7_CPU) + select HAVE_IRQ_EXIT_ON_IRQ_STACK + select HAVE_KERNEL_GZIP select HAVE_KPROBES - select HAVE_ARCH_KGDB select HAVE_KRETPROBES - select HAVE_ARCH_TRACEHOOK + select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS select HAVE_MEMBLOCK select HAVE_MEMBLOCK_NODE_MAP - select HAVE_DMA_API_DEBUG + select HAVE_MOD_ARCH_SPECIFIC + select HAVE_NMI if PERF_EVENTS select HAVE_OPROFILE - select HAVE_DEBUG_KMEMLEAK - select ARCH_HAS_SG_CHAIN - select GENERIC_ATOMIC64 if PPC32 select HAVE_PERF_EVENTS + select HAVE_PERF_EVENTS_NMI if PPC64 select HAVE_PERF_REGS select HAVE_PERF_USER_STACK_DUMP + select HAVE_RCU_TABLE_FREE if SMP select HAVE_REGS_AND_STACK_ACCESS_API - select HAVE_HW_BREAKPOINT if PERF_EVENTS && (PPC_BOOK3S || PPC_8xx) - select ARCH_WANT_IPC_PARSE_VERSION - select SPARSE_IRQ + select HAVE_SYSCALL_TRACEPOINTS + select HAVE_VIRT_CPU_ACCOUNTING select IRQ_DOMAIN - select GENERIC_IRQ_SHOW - select GENERIC_IRQ_SHOW_LEVEL select IRQ_FORCED_THREADING - select HAVE_RCU_TABLE_FREE if SMP - select HAVE_SYSCALL_TRACEPOINTS - select HAVE_CBPF_JIT if !PPC64 - select HAVE_EBPF_JIT if PPC64 - select HAVE_ARCH_JUMP_LABEL - select ARCH_HAVE_NMI_SAFE_CMPXCHG - select ARCH_HAS_GCOV_PROFILE_ALL - select GENERIC_SMP_IDLE_THREAD - select GENERIC_CMOS_UPDATE - select GENERIC_TIME_VSYSCALL_OLD -
Re: [RFC v2 06/10] KVM: arm/arm64: Update the physical timer interrupt level
On 30/01/17 15:02, Christoffer Dall wrote:
> On Sun, Jan 29, 2017 at 03:21:06PM +, Marc Zyngier wrote:
>> On Fri, Jan 27 2017 at 01:04:56 AM, Jintack Lim
>> wrote:
>>> Now that we maintain the EL1 physical timer register states of VMs,
>>> update the physical timer interrupt level along with the virtual one.
>>>
>>> Note that the emulated EL1 physical timer is not mapped to any hardware
>>> timer, so we call a proper vgic function.
>>>
>>> Signed-off-by: Jintack Lim
>>> ---
>>> virt/kvm/arm/arch_timer.c | 20
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>>> index 0f6e935..3b6bd50 100644
>>> --- a/virt/kvm/arm/arch_timer.c
>>> +++ b/virt/kvm/arm/arch_timer.c
>>> @@ -180,6 +180,21 @@ static void kvm_timer_update_mapped_irq(struct
>>> kvm_vcpu *vcpu, bool new_level,
>>> WARN_ON(ret);
>>> }
>>>
>>> +static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
>>> +struct arch_timer_context *timer)
>>> +{
>>> + int ret;
>>> +
>>> + BUG_ON(!vgic_initialized(vcpu->kvm));
>>
>> Although I've added my fair share of BUG_ON() in the code base, I've
>> since reconsidered my position. If we get in a situation where the vgic
>> is not initialized, maybe it would be better to just WARN_ON and return
>> early rather than killing the whole box. Thoughts?
>>
>
> The distinction to me is whether this will cause fatal crashes or
> exploits down the road if we're working on uninitialized data. If all
> that can happen if the vgic is not initialized, is that the guest
> doesn't see interrupts, for example, then a WARN_ON is appropriate.
>
> Which is the case here?
>
> That being said, do we need this at all? This is in the critial path
> and is actually measurable (I know this from my work on the other timer
> series), so it's better to get rid of it if we can. Can we simply
> convince ourselves this will never happen, and is the code ever likely
> to change so that it gets called with the vgic disabled later?
That'd be the best course of action. I remember us reworking some of
that in the now defunct vgic-less series. Maybe we could salvage that
code, if only for the time we spent on it...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [GIT PULL 4/4] arm64: dts: exynos: for v4.11, 2nd round
On Sun, Jan 29, 2017 at 09:23:29PM -0800, Olof Johansson wrote: > Hi Krzysztof, > > On Sun, Jan 29, 2017 at 10:06:29PM +0200, Krzysztof Kozlowski wrote: > > Hi, > > > > On top of previous pull request. > > > > This adds proper clocks to LPASS node on Exynos5433 which is needed > > by Marek's patchset: > > - [PATCH v2 0/8] Pad retentions support for Exynos5433 > >https://lkml.kernel.org/r/1485419634-28331-1-git-send-email-m.szyprowski > > () samsung ! com > > > > > > Cc: Marek Szyprowski > > Cc: Sylwester Nawrocki > > Cc: Linus Walleij > > Cc: Tomasz Figa > > Cc: Lee Jones > > > > Best regards, > > Krzysztof > > > > > > The following changes since commit e4e381133241a27d732e78be09973b89a193eaf7: > > > > arm64: dts: exynos: Enable HDMI/TV path on Exynos5433-TM2 (2017-01-11 > > 18:20:28 +0200) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > > tags/samsung-dt64-4.11-2 > > > > for you to fetch changes up to 7547162ac351483df3641f64e99e10be329dd6a2: > > > > arm64: dts: exynos: Add clocks to Exynos5433 LPASS module (2017-01-26 > > 22:04:20 +0200) > > I think you tagged the wrong branch here. The log message shows the right hash > at the tip, but the tag is of 95648b747071d530b5bb983735cfe01b66bf, which > seems to be on your for-next. > > Care to respin, so your tag and our merged branch match up? > Fixed, the same name of tag but this time on proper branch: tag namesamsung-dt64-4.11-2 https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/dt64 Sorry for the mess. Best regards, Krzysztof
[PATCH] tick/broadcast: Reduce lock cacheline contention
It was observed that on an Intel x86 system without the ARAT (Always
running APIC timer) feature and with fairly large number of CPUs as
well as CPUs coming in and out of intel_idle frequently, the lock
contention on the tick_broadcast_lock can become significant.
To reduce contention, the lock is put into its own cacheline and all
the cpumask_var_t variables are put into the __read_mostly section.
Running the SP benchmark of the NAS Parallel Benchmarks on a 4-socket
16-core 32-thread Nehalam system, the performance number improved
from 3353.94 Mop/s to 3469.31 Mop/s when this patch was applied on
a 4.9.6 kernel. This is a 3.4% improvement.
Signed-off-by: Waiman Long
---
include/linux/cpumask.h | 7 ++-
kernel/time/tick-broadcast.c | 15 ---
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index c717f5e..23c1a6d 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -649,11 +649,15 @@ static inline size_t cpumask_size(void)
* used. Please use this_cpu_cpumask_var_t in those cases. The direct use
* of this_cpu_ptr() or this_cpu_read() will lead to failures when the
* other type of cpumask_var_t implementation is configured.
+ *
+ * Please also note that __cpumask_var_read_mostly can be used to declare
+ * a cpumask_var_t variable itself (not its content) as read mostly.
*/
#ifdef CONFIG_CPUMASK_OFFSTACK
typedef struct cpumask *cpumask_var_t;
-#define this_cpu_cpumask_var_ptr(x) this_cpu_read(x)
+#define this_cpu_cpumask_var_ptr(x)this_cpu_read(x)
+#define __cpumask_var_read_mostly __read_mostly
bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node);
bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags);
@@ -667,6 +671,7 @@ static inline size_t cpumask_size(void)
typedef struct cpumask cpumask_var_t[1];
#define this_cpu_cpumask_var_ptr(x) this_cpu_ptr(x)
+#define __cpumask_var_read_mostly
static inline bool alloc_cpumask_var(cpumask_var_t *mask, gfp_t flags)
{
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 3109204..244c935 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -29,12 +29,13 @@
*/
static struct tick_device tick_broadcast_device;
-static cpumask_var_t tick_broadcast_mask;
-static cpumask_var_t tick_broadcast_on;
-static cpumask_var_t tmpmask;
-static DEFINE_RAW_SPINLOCK(tick_broadcast_lock);
+static cpumask_var_t tick_broadcast_mask __cpumask_var_read_mostly;
+static cpumask_var_t tick_broadcast_on __cpumask_var_read_mostly;
+static cpumask_var_t tmpmask __cpumask_var_read_mostly;
static int tick_broadcast_forced;
+static __cacheline_aligned_in_smp DEFINE_RAW_SPINLOCK(tick_broadcast_lock);
+
#ifdef CONFIG_TICK_ONESHOT
static void tick_broadcast_clear_oneshot(int cpu);
static void tick_resume_broadcast_oneshot(struct clock_event_device *bc);
@@ -517,9 +518,9 @@ void tick_resume_broadcast(void)
#ifdef CONFIG_TICK_ONESHOT
-static cpumask_var_t tick_broadcast_oneshot_mask;
-static cpumask_var_t tick_broadcast_pending_mask;
-static cpumask_var_t tick_broadcast_force_mask;
+static cpumask_var_t tick_broadcast_oneshot_mask __cpumask_var_read_mostly;
+static cpumask_var_t tick_broadcast_pending_mask __cpumask_var_read_mostly;
+static cpumask_var_t tick_broadcast_force_mask __cpumask_var_read_mostly;
/*
* Exposed for debugging: see timer_list.c
--
1.8.3.1
Re: [PATCH 5/5] gpio: ws16c48: Add support for GPIO names
Hi William,
[auto build test ERROR on gpio/for-next]
[also build test ERROR on next-20170130]
[cannot apply to v4.10-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/gpio-Add-support-for-GPIO-names-for-several-ISA_BUS_API-drivers/20170131-013038
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
for-next
config: i386-randconfig-x003-201705 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpio/gpio-ws16c48.c: In function 'ws16c48_probe':
>> drivers/gpio/gpio-ws16c48.c:381:28: error: 'ws16c48_names' undeclared (first
>> use in this function)
ws16c48gpio->chip.names = ws16c48_names;
^
drivers/gpio/gpio-ws16c48.c:381:28: note: each undeclared identifier is
reported only once for each function it appears in
At top level:
drivers/gpio/gpio-ws16c48.c:345:20: warning: 'ws14c48_names' defined but not
used [-Wunused-variable]
static const char *ws14c48_names[WS16C48_NGPIO] = {
^
vim +/ws16c48_names +381 drivers/gpio/gpio-ws16c48.c
375
376 ws16c48gpio->chip.label = name;
377 ws16c48gpio->chip.parent = dev;
378 ws16c48gpio->chip.owner = THIS_MODULE;
379 ws16c48gpio->chip.base = -1;
380 ws16c48gpio->chip.ngpio = WS16C48_NGPIO;
> 381 ws16c48gpio->chip.names = ws16c48_names;
382 ws16c48gpio->chip.get_direction = ws16c48_gpio_get_direction;
383 ws16c48gpio->chip.direction_input =
ws16c48_gpio_direction_input;
384 ws16c48gpio->chip.direction_output =
ws16c48_gpio_direction_output;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC V2 11/12] mm: Tag VMA with VM_CDM flag during page fault
Here's the flag definition:
> +#ifdef CONFIG_COHERENT_DEVICE
> +#define VM_CDM 0x0080 /* Contains coherent device
> memory */
> +#endif
But it doesn't match the implementation:
> +#ifdef CONFIG_COHERENT_DEVICE
> +static void mark_vma_cdm(nodemask_t *nmask,
> + struct page *page, struct vm_area_struct *vma)
> +{
> + if (!page)
> + return;
> +
> + if (vma->vm_flags & VM_CDM)
> + return;
> +
> + if (nmask && !nodemask_has_cdm(*nmask))
> + return;
> +
> + if (is_cdm_node(page_to_nid(page)))
> + vma->vm_flags |= VM_CDM;
> +}
That flag is a one-way trip. Any VMA with that flag set on it will keep
it for the life of the VMA, despite whether it has CDM pages in it now
or not. Even if you changed the policy back to one that doesn't allow
CDM and forced all the pages to be migrated out.
This also assumes that the only way to get a page mapped into a VMA is
via alloc_pages_vma(). Do the NUMA migration APIs use this path?
When you *set* this flag, you don't go and turn off KSM merging, for
instance. You keep it from being turned on from this point forward, but
you don't turn it off.
This is happening with mmap_sem held for read. Correct? Is it OK that
you're modifying the VMA? That vm_flags manipulation is non-atomic, so
how can that even be safe?
If you're going to go down this route, I think you need to be very
careful. We need to ensure that when this flag gets set, it's never set
on VMAs that are "normal" and will only be set on VMAs that were
*explicitly* set up for accessing CDM. That means that you'll need to
make sure that there's no possible way to get a CDM page faulted into a
VMA unless it's via an explicitly assigned policy that would have cause
the VMA to be split from any "normal" one in the system.
This all makes me really nervous.
Re: [PATCH v3 06/24] drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf
On Sun, Jan 29, 2017 at 01:24:26PM +, John Keeping wrote:
> As a side-effect of this, encode the endianness explicitly rather than
> casting a u16.
>
> Signed-off-by: John Keeping
> Reviewed-by: Chris Zhong
> ---
> v3:
> - Add Chris' Reviewed-by
> Unchanged in v2
>
> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 4be1ff3a42bb..2e6ad4591ebf 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -572,8 +572,13 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct
> dw_mipi_dsi *dsi, u32 hdr_val)
> static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
> const struct mipi_dsi_msg *msg)
> {
> - const u16 *tx_buf = msg->tx_buf;
> - u32 val = GEN_HDATA(*tx_buf) | GEN_HTYPE(msg->type);
> + const u8 *tx_buf = msg->tx_buf;
> + u32 val = GEN_HTYPE(msg->type);
> +
> + if (msg->tx_len > 0)
> + val |= GEN_HDATA(tx_buf[0]);
> + if (msg->tx_len > 1)
> + val |= GEN_HDATA(tx_buf[1] << 8);
You should probably update the mask inside GEN_HDATA to mask off 8 bits instead
of
16.
Sean
>
> if (msg->tx_len > 2) {
> dev_err(dsi->dev, "too long tx buf length %zu for short
> write\n",
> --
> 2.11.0.197.gb556de5.dirty
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
Re: [PATCH v3 07/24] drm/rockchip: dw-mipi-dsi: include bad value in error message
On Sun, Jan 29, 2017 at 01:24:27PM +, John Keeping wrote: > As an aid to debugging. Reviewed-by: Sean Paul > > Signed-off-by: John Keeping > Reviewed-by: Chris Zhong > --- > v3: > - Add Chris' Reviewed-by > Unchanged in v2 > > drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c > index 2e6ad4591ebf..92dbc3e56603 100644 > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c > @@ -644,7 +644,8 @@ static ssize_t dw_mipi_dsi_host_transfer(struct > mipi_dsi_host *host, > ret = dw_mipi_dsi_dcs_long_write(dsi, msg); > break; > default: > - dev_err(dsi->dev, "unsupported message type\n"); > + dev_err(dsi->dev, "unsupported message type 0x%02x\n", > + msg->type); > ret = -EINVAL; > } > > -- > 2.11.0.197.gb556de5.dirty > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS
Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
On Monday 30 January 2017 18:53:09 Tony Lindgren wrote: > * Pavel Machek [170127 11:41]: > > On Fri 2017-01-27 17:23:07, Kalle Valo wrote: > > > Pali Rohár writes: > > > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote: > > > >> Pali Rohár writes: > > > >> > 2) It was already tested that example NVS data can be used > > > >> > for N900 e.g. for SSH connection. If real correct data are > > > >> > not available it is better to use at least those example > > > >> > (and probably log warning message) so user can connect via > > > >> > SSH and start investigating where is problem. > > > >> > > > >> I disagree. Allowing default calibration data to be used can > > > >> be unnoticed by user and left her wondering why wifi works so > > > >> badly. > > > > > > > > So there are only two options: > > > > > > > > 1) Disallow it and so these users will have non-working wifi. > > > > > > > > 2) Allow those data to be used as fallback mechanism. > > > > > > > > And personally I'm against 1) because it will break wifi > > > > support for *all* Nokia N900 devices right now. > > > > > > All two of them? :) > > > > Umm. You clearly want a flock of angry penguins at your doorsteps > > :-). > > Well this silly issue of symlinking and renaming nvs files in a > standard Linux distro was also hitting me on various devices with > wl12xx/wl18xx trying to use the same rootfs. wl12xx/wl18xx have probably exactly same problem as wl1251. > Why don't we just set a custom compatible property for n900 that then > picks up some other nvs file instead of the default? But that still does not solve this problem correctly. Every n900 device have different NVS file. If we allow to load firmware directly from VFS without userspace helper we would see again same problem. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] PCI: ACPI: Fix ThunderX PEM initialization
On 01/30/2017 08:25 AM, Vadim Lomovtsev wrote:
This patch is to address PEM initialization issue
which causes network issues.
It is necessary to search for _HID:PNP0A08 while requesting
PEM resources via ACPI instead of "THRX0002".
Since this is fixing new code, there should be no chance to break
previously working systems.
Bjorn: If possible, this should be merged for v4.10
Signed-off-by: Vadim Lomovtsev
Acked-by: David Daney
---
drivers/pci/host/pci-thunder-pem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-thunder-pem.c
b/drivers/pci/host/pci-thunder-pem.c
index af722eb..aec30b8 100644
--- a/drivers/pci/host/pci-thunder-pem.c
+++ b/drivers/pci/host/pci-thunder-pem.c
@@ -331,7 +331,7 @@ static int thunder_pem_acpi_init(struct pci_config_window
*cfg)
if (!res_pem)
return -ENOMEM;
- ret = acpi_get_rc_resources(dev, "THRX0002", root->segment, res_pem);
+ ret = acpi_get_rc_resources(dev, "PNP0A08", root->segment, res_pem);
if (ret) {
dev_err(dev, "can't get rc base address\n");
return ret;
Re: [RFC v2 02/10] KVM: arm/arm64: Move cntvoff to each timer context
On 30/01/17 17:58, Jintack Lim wrote:
> On Sun, Jan 29, 2017 at 6:54 AM, Marc Zyngier wrote:
>> On Fri, Jan 27 2017 at 01:04:52 AM, Jintack Lim
>> wrote:
>>> Make cntvoff per each timer context. This is helpful to abstract kvm
>>> timer functions to work with timer context without considering timer
>>> types (e.g. physical timer or virtual timer).
>>>
>>> This also would pave the way for ever doing adjustments of the cntvoff
>>> on a per-CPU basis if that should ever make sense.
>>>
>>> Signed-off-by: Jintack Lim
>>> ---
>>> arch/arm/include/asm/kvm_host.h | 6 +++---
>>> arch/arm64/include/asm/kvm_host.h | 4 ++--
>>> include/kvm/arm_arch_timer.h | 8 +++-
>>> virt/kvm/arm/arch_timer.c | 26 --
>>> virt/kvm/arm/hyp/timer-sr.c | 3 +--
>>> 5 files changed, 29 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/kvm_host.h
>>> b/arch/arm/include/asm/kvm_host.h
>>> index d5423ab..f5456a9 100644
>>> --- a/arch/arm/include/asm/kvm_host.h
>>> +++ b/arch/arm/include/asm/kvm_host.h
>>> @@ -60,9 +60,6 @@ struct kvm_arch {
>>> /* The last vcpu id that ran on each physical CPU */
>>> int __percpu *last_vcpu_ran;
>>>
>>> - /* Timer */
>>> - struct arch_timer_kvm timer;
>>> -
>>> /*
>>>* Anything that is not used directly from assembly code goes
>>>* here.
>>> @@ -75,6 +72,9 @@ struct kvm_arch {
>>> /* Stage-2 page table */
>>> pgd_t *pgd;
>>>
>>> + /* A lock to synchronize cntvoff among all vtimer context of vcpus */
>>> + spinlock_t cntvoff_lock;
>>
>> Is there any condition where we need this to be a spinlock? I would have
>> thought that a mutex should have been enough, as this should only be
>> updated on migration or initialization. Not that it matters much in this
>> case, but I wondered if there is something I'm missing.
>>
>>> +
>>> /* Interrupt controller */
>>> struct vgic_distvgic;
>>> int max_vcpus;
>>> diff --git a/arch/arm64/include/asm/kvm_host.h
>>> b/arch/arm64/include/asm/kvm_host.h
>>> index e505038..23749a8 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -71,8 +71,8 @@ struct kvm_arch {
>>> /* Interrupt controller */
>>> struct vgic_distvgic;
>>>
>>> - /* Timer */
>>> - struct arch_timer_kvm timer;
>>> + /* A lock to synchronize cntvoff among all vtimer context of vcpus */
>>> + spinlock_t cntvoff_lock;
>>> };
>>>
>>> #define KVM_NR_MEM_OBJS 40
>>> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
>>> index daad3c1..1b9c988 100644
>>> --- a/include/kvm/arm_arch_timer.h
>>> +++ b/include/kvm/arm_arch_timer.h
>>> @@ -23,11 +23,6 @@
>>> #include
>>> #include
>>>
>>> -struct arch_timer_kvm {
>>> - /* Virtual offset */
>>> - u64 cntvoff;
>>> -};
>>> -
>>> struct arch_timer_context {
>>> /* Registers: control register, timer value */
>>> u32 cnt_ctl;
>>> @@ -38,6 +33,9 @@ struct arch_timer_context {
>>>
>>> /* Active IRQ state caching */
>>> boolactive_cleared_last;
>>> +
>>> + /* Virtual offset */
>>> + u64 cntvoff;
>>> };
>>>
>>> struct arch_timer_cpu {
>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>>> index 6740efa..fa4c042 100644
>>> --- a/virt/kvm/arm/arch_timer.c
>>> +++ b/virt/kvm/arm/arch_timer.c
>>> @@ -101,9 +101,10 @@ static void kvm_timer_inject_irq_work(struct
>>> work_struct *work)
>>> static u64 kvm_timer_compute_delta(struct kvm_vcpu *vcpu)
>>> {
>>> u64 cval, now;
>>> + struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>>>
>>> - cval = vcpu_vtimer(vcpu)->cnt_cval;
>>> - now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
>>> + cval = vtimer->cnt_cval;
>>> + now = kvm_phys_timer_read() - vtimer->cntvoff;
>>>
>>> if (now < cval) {
>>> u64 ns;
>>> @@ -159,7 +160,7 @@ bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
>>> return false;
>>>
>>> cval = vtimer->cnt_cval;
>>> - now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
>>> + now = kvm_phys_timer_read() - vtimer->cntvoff;
>>>
>>> return cval <= now;
>>> }
>>> @@ -353,10 +354,23 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>>> return 0;
>>> }
>>>
>>> +/* Make the updates of cntvoff for all vtimer contexts atomic */
>>> +static void update_vtimer_cntvoff(struct kvm_vcpu *vcpu, u64 cntvoff)
>>
>> Arguably, this acts on the VM itself and not a single vcpu. maybe you
>> should consider passing the struct kvm pointer to reflect this.
>>
>
> Yes, that would be better.
>
>>> +{
>>> + int i;
>>> +
>>> + spin_lock(&vcpu->kvm->arch.cntvoff_lock);
>>> + kvm_for_each_vcpu(i, vcpu, vcpu->kvm)
>>> + vcpu_vtimer(vcpu)->cntvoff = cntvoff;
>>> + spin_unlock
Re: [PATCH] xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()
On Mon, 2017-01-30 at 12:45 -0500, Boris Ostrovsky wrote:
> rx_refill_timer should be deleted as soon as we disconnect from the
> backend since otherwise it is possible for the timer to go off before
> we get to xennet_destroy_queues(). If this happens we may dereference
> queue->rx.sring which is set to NULL in xennet_disconnect_backend().
>
> Signed-off-by: Boris Ostrovsky
> CC: sta...@vger.kernel.org
> ---
> drivers/net/xen-netfront.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 8315fe7..722fe9f 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1379,6 +1379,8 @@ static void xennet_disconnect_backend(struct
> netfront_info *info)
> for (i = 0; i < num_queues && info->queues; ++i) {
> struct netfront_queue *queue = &info->queues[i];
>
> + del_timer_sync(&queue->rx_refill_timer);
> +
If napi_disable() was not called before this del_timer_sync(), another
RX might come here and rearm rx_refill_timer.
> if (queue->tx_irq && (queue->tx_irq == queue->rx_irq))
> unbind_from_irqhandler(queue->tx_irq, queue);
> if (queue->tx_irq && (queue->tx_irq != queue->rx_irq)) {
> @@ -1733,7 +1735,6 @@ static void xennet_destroy_queues(struct netfront_info
> *info)
>
> if (netif_running(info->netdev))
> napi_disable(&queue->napi);
> - del_timer_sync(&queue->rx_refill_timer);
> netif_napi_del(&queue->napi);
> }
>
Re: [PATCH v2 0/2] drm: Add support for tiny LCD displays
On Mon, Jan 30, 2017 at 04:03:53PM +0100, Noralf Trønnes wrote:
>
> Den 30.01.2017 09.44, skrev Daniel Vetter:
> > Hi Noralf,
> >
> > On Fri, Jan 27, 2017 at 08:56:29PM +0100, Noralf Trønnes wrote:
> > > This is an attempt at providing a DRM version of drivers/staging/fbtft.
> > >
> > > The tinydrm library provides a very simplified view of DRM in particular
> > > for tiny displays that has onboard video memory and is connected through
> > > a slow bus like SPI/I2C.
> > >
> > > Only core patches this time.
> > >
> > >
> > > Noralf.
> > >
> > >
> > > Changes since version 1:
> > > - Add tinydrm.rst
> > > - Set tdev->fbdev_cma=NULL on unregister (lastclose is called after that).
> > Hm, this sounds like a buglet in the drm framework ... how do we call
> > lastclose when the driver is disappearing? I do see a drm_lastclose call
> > at the beginning of drm_dev_unregister (which we might want to remove for
> > KMS drivers, it doesn't make much sense imo), but that shouldn't result in
> > troubles.
>
> Ah, I see, I'm tearing down fbdev before unregistering drm.
> That should be reversed.
>
> static void tinydrm_unregister(struct tinydrm_device *tdev)
> {
> drm_crtc_force_disable_all(tdev->drm);
>
> if (tdev->fbdev_cma) {
> drm_fbdev_cma_fini(tdev->fbdev_cma);
> tdev->fbdev_cma = NULL;
> }
>
> drm_dev_unregister(tdev->drm);
> }
>
> > > - Remove some DRM_DEBUG*()
> > > - Write-combined memory has uncached reads, so speed up by
> > > copying/buffering
> > >one pixel line before conversion.
> > Hm, why are you using write-combining memory? Or is that needed so that
> > you can (if available) use hw spi engines?
>
> That comes with using the CMA helper:
> drm_fbdev_cma_create_with_funcs() -> drm_gem_cma_create() -> dma_alloc_wc()
>
> Here's a comment I have added in the code for why I set the DMA mask on
> the SPI device and why it will work:
>
> /*
> * Even though it's not the SPI device that does DMA (the master does),
> * the dma mask is necessary for the dma_alloc_wc() in
> * drm_gem_cma_create(). The dma_addr returned will be a physical
> * adddress which might be different from the bus address, but this is
> * not a problem since the address will not be used.
> * The virtual address is used in the transfer and the SPI core
> * re-maps it on the SPI master device using the DMA streaming API
> * (spi_map_buf()).
> */
>
> > Either way, I think this all looks good, pls submit a pull request to Dave
> > with these two patches as soon as latest drm-misc has landed (I'll send a
> > pull request for that later today).
>
> I'm confused, I thought you wanted the core patches through drm-misc
> and the rest as a pull request to Dave.
>
> This is what you said:
>
> Looks all pretty. A bunch of ideas below, but all optional. For merging
> I
> think simplest to first get the core patches in through drm-misc, and
> then
> you can submit a pull request to Dave for tinydrm+backends (just needs
> an
> ack for the dt parts from dt maintainers), including MAINTAINERS entry.
> Ack from my side.
Ah, I thought we already have all the prep patches you need merged into
drm-misc. Still the same plan.
> > Another one: Do you want to maintain tinydrm as part of the drm-misc
> > group, i.e. want commit rights there? That would also help a bit with
> > pushing all your great drm refactoring patches through the machinery ...
>
> My goal is to port staging/fbtft to drm. Whether or not I will do work
> in drm core (refactoring) besides the tinydrm drivers when that is
> accomplished, I don't know. Working on drm as a hobbyist is very
> difficult (for me at least) because it is very complex, it changes all
> the time and on top of that it has a high volume mailinglist.
> It takes effort to keep up.
>
> So I will probably end up doing only tinydrm maintanence.
> As for how that is best done, I don't know. Once I have covered a 3-4
> controller types, a new driver is just a copy of a similar one with a
> different register initialization. This means that it's easy to review
> patches. They will all look the same, more or less.
> So for me it's ofc best if I can review the patches and then commit
> them myself. As for my own patches, if I need that tit for tat
> reviewing to get them in, it will be difficult for me to review other
> drivers because I have no idea how a GPU operates, and to keep up with
> drm best pratices will be next to impossible for me.
I think you're slightly understating your knowledge about the display side
of drm here a bit :-) We're (for now) also only talking about getting
small display drivers into drm-misc.
> If the Device Tree guys allows me to add fbtft support to tinydrm, then
> there won't be much activity once the fbtft drivers have been ported
> over. The uncertainty stems from the fact that the fbtft drivers are
> written as controller drivers, but they contain panel specific things
Re: [PATCH 1/2] watchdog: sama5d4: Cache MR instead of a partial config
On Mon, Jan 30, 2017 at 06:18:47PM +0100, Alexandre Belloni wrote:
> .config is used to cache a part of WDT_MR at probe time and is not used
> afterwards. Instead of doing that, actually cache MR and avoid reading it
> every time it is modified.
>
The semantic change here is that the old code leaves "other" bits in the
mr register alone. I assume you have verified that clearing those bits
does not have negative impact.
Also, I am not really sure if replacing a read from a register is more
costly than a read from memory. Is that change really worth it ?
I mean, sure, the way the 'config' variable is used is a bit odd,
but I don't really see the improvement in its replacement either.
> Signed-off-by: Alexandre Belloni
> ---
> drivers/watchdog/sama5d4_wdt.c | 45
> ++
> 1 file changed, 19 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
> index a49634cdc1cc..6dd07bef515a 100644
> --- a/drivers/watchdog/sama5d4_wdt.c
> +++ b/drivers/watchdog/sama5d4_wdt.c
> @@ -28,7 +28,7 @@
> struct sama5d4_wdt {
> struct watchdog_device wdd;
> void __iomem*reg_base;
> - u32 config;
> + u32 mr;
> };
>
> static int wdt_timeout = WDT_DEFAULT_TIMEOUT;
> @@ -53,11 +53,9 @@ MODULE_PARM_DESC(nowayout,
> static int sama5d4_wdt_start(struct watchdog_device *wdd)
> {
> struct sama5d4_wdt *wdt = watchdog_get_drvdata(wdd);
> - u32 reg;
>
> - reg = wdt_read(wdt, AT91_WDT_MR);
> - reg &= ~AT91_WDT_WDDIS;
> - wdt_write(wdt, AT91_WDT_MR, reg);
> + wdt->mr &= ~AT91_WDT_WDDIS;
> + wdt_write(wdt, AT91_WDT_MR, wdt->mr);
>
> return 0;
> }
> @@ -65,11 +63,9 @@ static int sama5d4_wdt_start(struct watchdog_device *wdd)
> static int sama5d4_wdt_stop(struct watchdog_device *wdd)
> {
> struct sama5d4_wdt *wdt = watchdog_get_drvdata(wdd);
> - u32 reg;
>
> - reg = wdt_read(wdt, AT91_WDT_MR);
> - reg |= AT91_WDT_WDDIS;
> - wdt_write(wdt, AT91_WDT_MR, reg);
> + wdt->mr |= AT91_WDT_WDDIS;
> + wdt_write(wdt, AT91_WDT_MR, wdt->mr);
>
> return 0;
> }
> @@ -88,14 +84,12 @@ static int sama5d4_wdt_set_timeout(struct watchdog_device
> *wdd,
> {
> struct sama5d4_wdt *wdt = watchdog_get_drvdata(wdd);
> u32 value = WDT_SEC2TICKS(timeout);
> - u32 reg;
>
> - reg = wdt_read(wdt, AT91_WDT_MR);
> - reg &= ~AT91_WDT_WDV;
> - reg &= ~AT91_WDT_WDD;
> - reg |= AT91_WDT_SET_WDV(value);
> - reg |= AT91_WDT_SET_WDD(value);
> - wdt_write(wdt, AT91_WDT_MR, reg);
> + wdt->mr &= ~AT91_WDT_WDV;
> + wdt->mr &= ~AT91_WDT_WDD;
> + wdt->mr |= AT91_WDT_SET_WDV(value);
> + wdt->mr |= AT91_WDT_SET_WDD(value);
> + wdt_write(wdt, AT91_WDT_MR, wdt->mr);
>
> wdd->timeout = timeout;
>
> @@ -132,19 +126,19 @@ static int of_sama5d4_wdt_init(struct device_node *np,
> struct sama5d4_wdt *wdt)
> {
> const char *tmp;
>
> - wdt->config = AT91_WDT_WDDIS;
> + wdt->mr = AT91_WDT_WDDIS;
>
> if (!of_property_read_string(np, "atmel,watchdog-type", &tmp) &&
> !strcmp(tmp, "software"))
> - wdt->config |= AT91_WDT_WDFIEN;
> + wdt->mr |= AT91_WDT_WDFIEN;
> else
> - wdt->config |= AT91_WDT_WDRSTEN;
> + wdt->mr |= AT91_WDT_WDRSTEN;
>
> if (of_property_read_bool(np, "atmel,idle-halt"))
> - wdt->config |= AT91_WDT_WDIDLEHLT;
> + wdt->mr |= AT91_WDT_WDIDLEHLT;
>
> if (of_property_read_bool(np, "atmel,dbg-halt"))
> - wdt->config |= AT91_WDT_WDDBGHLT;
> + wdt->mr |= AT91_WDT_WDDBGHLT;
>
> return 0;
> }
> @@ -163,11 +157,10 @@ static int sama5d4_wdt_init(struct sama5d4_wdt *wdt)
> reg &= ~AT91_WDT_WDDIS;
> wdt_write(wdt, AT91_WDT_MR, reg);
>
There is (at least) one read of the mr register left above this code.
It is not entirely obvious to me why it would make sense to retain
this single read instead of just clearing the AT91_WDT_WDDIS bit
from the cached value and writing the rest. Maybe this is to make
sure that WDV or WDD isn't changed with the bit set, but
the explanation associated with clearing the bit is a bit odd either
case. It states that AT91_WDT_WDDIS must not be set (meaning the watchdog
must be running ? Shouldn't it be the opposite ?) when changing WDV or WDD,
then violates this rule when updating the timeout (which can happen with
the watchdog running or not).
> - reg = wdt->config;
> - reg |= AT91_WDT_SET_WDD(value);
> - reg |= AT91_WDT_SET_WDV(value);
> + wdt->mr |= AT91_WDT_SET_WDD(value);
> + wdt->mr |= AT91_WDT_SET_WDV(value);
>
> - wdt_write(wdt, AT91_WDT_MR, reg);
> + wdt_write(wdt, AT91_WDT_MR, wdt->mr);
>
> return 0;
> }
> @@ -211,7 +204,7 @@ static int sama5d4_wdt_probe(struct platform_device *pdev)
> return ret;
> }
>
Re: setns() && PR_SET_CHILD_SUBREAPER
Hi Eric, sorry for delay, I was sick. On 01/25, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > > So what do you think about the patch below? > > That does look like the correct logic. Great, > Whose tree do we want to run merge these fixes through? I can pick them > up if that would be convinient. Thanks! this would be nice, I am sending the patch. Oleg.
Re: [PATCH v3 06/24] drm/rockchip: dw-mipi-dsi: avoid out-of-bounds read on tx_buf
On Mon, 30 Jan 2017 13:01:46 -0500, Sean Paul wrote:
> On Sun, Jan 29, 2017 at 01:24:26PM +, John Keeping wrote:
> > As a side-effect of this, encode the endianness explicitly rather than
> > casting a u16.
> >
> > Signed-off-by: John Keeping
> > Reviewed-by: Chris Zhong
> > ---
> > v3:
> > - Add Chris' Reviewed-by
> > Unchanged in v2
> >
> > drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > index 4be1ff3a42bb..2e6ad4591ebf 100644
> > --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> > @@ -572,8 +572,13 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct
> > dw_mipi_dsi *dsi, u32 hdr_val)
> > static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
> >const struct mipi_dsi_msg *msg)
> > {
> > - const u16 *tx_buf = msg->tx_buf;
> > - u32 val = GEN_HDATA(*tx_buf) | GEN_HTYPE(msg->type);
> > + const u8 *tx_buf = msg->tx_buf;
> > + u32 val = GEN_HTYPE(msg->type);
> > +
> > + if (msg->tx_len > 0)
> > + val |= GEN_HDATA(tx_buf[0]);
> > + if (msg->tx_len > 1)
> > + val |= GEN_HDATA(tx_buf[1] << 8);
>
> You should probably update the mask inside GEN_HDATA to mask off 8 bits
> instead of
> 16.
Won't that mask off the data written by "tx_buf[1] << 8"?
Re: [RFC v2 02/10] KVM: arm/arm64: Move cntvoff to each timer context
On Sun, Jan 29, 2017 at 6:54 AM, Marc Zyngier wrote:
> On Fri, Jan 27 2017 at 01:04:52 AM, Jintack Lim
> wrote:
>> Make cntvoff per each timer context. This is helpful to abstract kvm
>> timer functions to work with timer context without considering timer
>> types (e.g. physical timer or virtual timer).
>>
>> This also would pave the way for ever doing adjustments of the cntvoff
>> on a per-CPU basis if that should ever make sense.
>>
>> Signed-off-by: Jintack Lim
>> ---
>> arch/arm/include/asm/kvm_host.h | 6 +++---
>> arch/arm64/include/asm/kvm_host.h | 4 ++--
>> include/kvm/arm_arch_timer.h | 8 +++-
>> virt/kvm/arm/arch_timer.c | 26 --
>> virt/kvm/arm/hyp/timer-sr.c | 3 +--
>> 5 files changed, 29 insertions(+), 18 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_host.h
>> b/arch/arm/include/asm/kvm_host.h
>> index d5423ab..f5456a9 100644
>> --- a/arch/arm/include/asm/kvm_host.h
>> +++ b/arch/arm/include/asm/kvm_host.h
>> @@ -60,9 +60,6 @@ struct kvm_arch {
>> /* The last vcpu id that ran on each physical CPU */
>> int __percpu *last_vcpu_ran;
>>
>> - /* Timer */
>> - struct arch_timer_kvm timer;
>> -
>> /*
>>* Anything that is not used directly from assembly code goes
>>* here.
>> @@ -75,6 +72,9 @@ struct kvm_arch {
>> /* Stage-2 page table */
>> pgd_t *pgd;
>>
>> + /* A lock to synchronize cntvoff among all vtimer context of vcpus */
>> + spinlock_t cntvoff_lock;
>
> Is there any condition where we need this to be a spinlock? I would have
> thought that a mutex should have been enough, as this should only be
> updated on migration or initialization. Not that it matters much in this
> case, but I wondered if there is something I'm missing.
>
>> +
>> /* Interrupt controller */
>> struct vgic_distvgic;
>> int max_vcpus;
>> diff --git a/arch/arm64/include/asm/kvm_host.h
>> b/arch/arm64/include/asm/kvm_host.h
>> index e505038..23749a8 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -71,8 +71,8 @@ struct kvm_arch {
>> /* Interrupt controller */
>> struct vgic_distvgic;
>>
>> - /* Timer */
>> - struct arch_timer_kvm timer;
>> + /* A lock to synchronize cntvoff among all vtimer context of vcpus */
>> + spinlock_t cntvoff_lock;
>> };
>>
>> #define KVM_NR_MEM_OBJS 40
>> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
>> index daad3c1..1b9c988 100644
>> --- a/include/kvm/arm_arch_timer.h
>> +++ b/include/kvm/arm_arch_timer.h
>> @@ -23,11 +23,6 @@
>> #include
>> #include
>>
>> -struct arch_timer_kvm {
>> - /* Virtual offset */
>> - u64 cntvoff;
>> -};
>> -
>> struct arch_timer_context {
>> /* Registers: control register, timer value */
>> u32 cnt_ctl;
>> @@ -38,6 +33,9 @@ struct arch_timer_context {
>>
>> /* Active IRQ state caching */
>> boolactive_cleared_last;
>> +
>> + /* Virtual offset */
>> + u64 cntvoff;
>> };
>>
>> struct arch_timer_cpu {
>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>> index 6740efa..fa4c042 100644
>> --- a/virt/kvm/arm/arch_timer.c
>> +++ b/virt/kvm/arm/arch_timer.c
>> @@ -101,9 +101,10 @@ static void kvm_timer_inject_irq_work(struct
>> work_struct *work)
>> static u64 kvm_timer_compute_delta(struct kvm_vcpu *vcpu)
>> {
>> u64 cval, now;
>> + struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
>>
>> - cval = vcpu_vtimer(vcpu)->cnt_cval;
>> - now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
>> + cval = vtimer->cnt_cval;
>> + now = kvm_phys_timer_read() - vtimer->cntvoff;
>>
>> if (now < cval) {
>> u64 ns;
>> @@ -159,7 +160,7 @@ bool kvm_timer_should_fire(struct kvm_vcpu *vcpu)
>> return false;
>>
>> cval = vtimer->cnt_cval;
>> - now = kvm_phys_timer_read() - vcpu->kvm->arch.timer.cntvoff;
>> + now = kvm_phys_timer_read() - vtimer->cntvoff;
>>
>> return cval <= now;
>> }
>> @@ -353,10 +354,23 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>> return 0;
>> }
>>
>> +/* Make the updates of cntvoff for all vtimer contexts atomic */
>> +static void update_vtimer_cntvoff(struct kvm_vcpu *vcpu, u64 cntvoff)
>
> Arguably, this acts on the VM itself and not a single vcpu. maybe you
> should consider passing the struct kvm pointer to reflect this.
>
Yes, that would be better.
>> +{
>> + int i;
>> +
>> + spin_lock(&vcpu->kvm->arch.cntvoff_lock);
>> + kvm_for_each_vcpu(i, vcpu, vcpu->kvm)
>> + vcpu_vtimer(vcpu)->cntvoff = cntvoff;
>> + spin_unlock(&vcpu->kvm->arch.cntvoff_lock);
>> +}
>> +
>> void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu)
>> {
>> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>>
>> + upda
[PATCH 2/2] watchdog: ts72xx_wdt: convert driver to watchdog core
Cleanup this driver and convert it to use the watchdog framework API.
Signed-off-by: H Hartley Sweeten
Cc: Mika Westerberg
Cc: Wim Van Sebroeck
Cc: Guenter Roeck
---
drivers/watchdog/ts72xx_wdt.c | 447 +-
1 file changed, 93 insertions(+), 354 deletions(-)
diff --git a/drivers/watchdog/ts72xx_wdt.c b/drivers/watchdog/ts72xx_wdt.c
index 4b54193..857ab71 100644
--- a/drivers/watchdog/ts72xx_wdt.c
+++ b/drivers/watchdog/ts72xx_wdt.c
@@ -13,413 +13,149 @@
* warranty of any kind, whether express or implied.
*/
-#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
+#include
#include
-#include
-
-#define TS72XX_WDT_FEED_VAL0x05
-#define TS72XX_WDT_DEFAULT_TIMEOUT 8
-
-static int timeout = TS72XX_WDT_DEFAULT_TIMEOUT;
-module_param(timeout, int, 0);
-MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds. "
- "(1 <= timeout <= 8, default="
- __MODULE_STRING(TS72XX_WDT_DEFAULT_TIMEOUT)
- ")");
+#include
static bool nowayout = WATCHDOG_NOWAYOUT;
module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout, "Disable watchdog shutdown on close");
-/**
- * struct ts72xx_wdt - watchdog control structure
- * @lock: lock that protects this structure
- * @regval: watchdog timeout value suitable for control register
- * @flags: flags controlling watchdog device state
- * @control_reg: watchdog control register
- * @feed_reg: watchdog feed register
- * @pdev: back pointer to platform dev
- */
-struct ts72xx_wdt {
- struct mutexlock;
- int regval;
-
-#define TS72XX_WDT_BUSY_FLAG 1
-#define TS72XX_WDT_EXPECT_CLOSE_FLAG 2
- int flags;
+/* priv->control_reg */
+#define TS72XX_WDT_CTRL_DISABLE0x00
+#define TS72XX_WDT_CTRL_250MS 0x01
+#define TS72XX_WDT_CTRL_500MS 0x02
+#define TS72XX_WDT_CTRL_1SEC 0x03
+#define TS72XX_WDT_CTRL_RESERVED 0x04
+#define TS72XX_WDT_CTRL_2SEC 0x05
+#define TS72XX_WDT_CTRL_4SEC 0x06
+#define TS72XX_WDT_CTRL_8SEC 0x07
+
+/* priv->feed_reg */
+#define TS72XX_WDT_FEED_VAL0x05
+struct ts72xx_wdt_priv {
void __iomem*control_reg;
void __iomem*feed_reg;
-
- struct platform_device *pdev;
+ struct watchdog_device wdd;
+ unsigned char regval;
};
-static struct platform_device *ts72xx_wdt_pdev;
-
-/*
- * TS-72xx Watchdog supports following timeouts (value written
- * to control register):
- * value description
- * -
- * 0x00watchdog disabled
- * 0x01250ms
- * 0x02500ms
- * 0x031s
- * 0x04reserved
- * 0x052s
- * 0x064s
- * 0x078s
- *
- * Timeouts below 1s are not very usable so we don't
- * allow them at all.
- *
- * We provide two functions that convert between these:
- * timeout_to_regval() and regval_to_timeout().
- */
-static const struct {
- int timeout;
- int regval;
-} ts72xx_wdt_map[] = {
- { 1, 3 },
- { 2, 5 },
- { 4, 6 },
- { 8, 7 },
-};
-
-/**
- * timeout_to_regval() - converts given timeout to control register value
- * @new_timeout: timeout in seconds to be converted
- *
- * Function converts given @new_timeout into valid value that can
- * be programmed into watchdog control register. When conversion is
- * not possible, function returns %-EINVAL.
- */
-static int timeout_to_regval(int new_timeout)
+static int ts72xx_wdt_start(struct watchdog_device *wdd)
{
- int i;
+ struct ts72xx_wdt_priv *priv = watchdog_get_drvdata(wdd);
- /* first limit it to 1 - 8 seconds */
- new_timeout = clamp_val(new_timeout, 1, 8);
+ writeb(TS72XX_WDT_FEED_VAL, priv->feed_reg);
+ writeb(priv->regval, priv->control_reg);
- for (i = 0; i < ARRAY_SIZE(ts72xx_wdt_map); i++) {
- if (ts72xx_wdt_map[i].timeout >= new_timeout)
- return ts72xx_wdt_map[i].regval;
- }
-
- return -EINVAL;
-}
-
-/**
- * regval_to_timeout() - converts control register value to timeout
- * @regval: control register value to be converted
- *
- * Function converts given @regval to timeout in seconds (1, 2, 4 or 8).
- * If @regval cannot be converted, function returns %-EINVAL.
- */
-static int regval_to_timeout(int regval)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(ts72xx_wdt_map); i++) {
- if (ts72xx_wdt_map[i].regval == regval)
- return ts72xx_wdt_map[i].timeout;
- }
-
- return -EINVAL;
-}
-
-/**
- * ts72xx_wdt_kick() - kick the watchdog
- * @wdt: watchdog to be kicked
- *
- * Called with @wdt->lock held.
- */
-static inline void ts72xx_wdt_kick(struct ts72xx_wdt *wdt)
-{
- __raw_writeb(TS72XX_WDT_FEED_VAL, wdt->feed_reg);
-}
-
-/**
- * ts72xx_wdt_start() - starts the watchdog timer
-
Re: [RFC V2 05/12] cpuset: Add cpuset_inc() inside cpuset_init()
On 01/29/2017 07:35 PM, Anshuman Khandual wrote:
> Currently cpusets_enabled() wrongfully returns 0 even if we have a root
> cpuset configured on the system. This got missed when jump level was
> introduced in place of number_of_cpusets with the commit 664eeddeef65
> ("mm: page_alloc: use jump labels to avoid checking number_of_cpusets")
> . This fixes the problem so that cpusets_enabled() returns positive even
> for the root cpuset.
>
> Fixes: 664eeddeef65 ("mm: page_alloc: use jump labels to avoid")
> Signed-off-by: Anshuman Khandual
This needs to go upstream separately, right?
