Re: [Xen-devel] [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON
On 20/02/16 01:27, Gonglei wrote:
> It's possible for a race condition to exist between xennet_open() and
> talk_to_netback(). After invoking netfront_probe() then other
> threads or processes invoke xennet_open (such as NetworkManager)
> immediately may trigger BUG_ON(). Besides, we also should reset
> real_num_tx_queues in xennet_destroy_queues().
I think you want something like the following. We serialize the backend
changing and the netdev open with the device mutex.
(I've not even tried to compile this so it might not even build.)
David
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d6abf19..7e2791a 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -340,22 +340,28 @@ static int xennet_open(struct net_device *dev)
unsigned int i = 0;
struct netfront_queue *queue = NULL;
+ device_lock(&np->xbdev->dev);
+
+ if (!netif_carrier_ok(dev))
+ goto unlock;
+
for (i = 0; i < num_queues; ++i) {
queue = &np->queues[i];
napi_enable(&queue->napi);
spin_lock_bh(&queue->rx_lock);
- if (netif_carrier_ok(dev)) {
- xennet_alloc_rx_buffers(queue);
- queue->rx.sring->rsp_event = queue->rx.rsp_cons + 1;
- if (RING_HAS_UNCONSUMED_RESPONSES(&queue->rx))
- napi_schedule(&queue->napi);
- }
+ xennet_alloc_rx_buffers(queue);
+ queue->rx.sring->rsp_event = queue->rx.rsp_cons + 1;
+ if (RING_HAS_UNCONSUMED_RESPONSES(&queue->rx))
+ napi_schedule(&queue->napi);
spin_unlock_bh(&queue->rx_lock);
}
netif_tx_start_all_queues(dev);
+ unlock:
+ device_unlock(&np->xbdev->dev);
+
return 0;
}
@@ -1983,8 +1989,8 @@ static int xennet_connect(struct net_device *dev)
num_queues = dev->real_num_tx_queues;
rtnl_lock();
+
netdev_update_features(dev);
- rtnl_unlock();
/*
* All public and private state should now be sane. Get
@@ -1992,7 +1998,6 @@ static int xennet_connect(struct net_device *dev)
* domain a kick because we've probably just requeued some
* packets.
*/
- netif_carrier_on(np->netdev);
for (j = 0; j < num_queues; ++j) {
queue = &np->queues[j];
@@ -2006,9 +2011,17 @@ static int xennet_connect(struct net_device *dev)
spin_lock_bh(&queue->rx_lock);
xennet_alloc_rx_buffers(queue);
+ if (netif_running(dev)) {
+ if (RING_HAS_UNCONSUMED_RESPONSES(&queue->rx))
+ napi_schedule(&queue->napi);
+ }
spin_unlock_bh(&queue->rx_lock);
}
+ netif_carrier_on(np->netdev);
+
+ rtnl_unlock();
+
return 0;
}
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index 33a31cf..57cd20d 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -204,8 +204,11 @@ void xenbus_otherend_changed(struct xenbus_watch
*watch,
return;
}
- if (drv->otherend_changed)
+ if (drv->otherend_changed) {
+ device_lock(&dev->dev);
drv->otherend_changed(dev, state);
+ device_unlock(&dev->dev);
+ }
}
EXPORT_SYMBOL_GPL(xenbus_otherend_changed);
[PATCHv1 1/3] coccinelle: also catch kzfree() issues
Since commit 3ef0e5ba4673 ('slab: introduce kzfree()'),
kfree() is no more the only function to be considered.
In particular, kzfree() must not be called on memory
allocated through devm_*() functions.
Cc: Johannes Weiner
Signed-off-by: Yann Droneaud
---
Hi Julia,
As you suggested, I've use disjunctions instead of regular
expressions (which I managed to use incorrectly: eg.
without ^...$ they catch other functions than kfree(),
such as kfree_skb()).
I've think we should also catch krealloc(, size), where size
is 0, but it's beyond my understanding of coccinelle if size
is not a plain 0 constant.
Perhaps you could help me for this one.
Regards.
scripts/coccinelle/free/devm_free.cocci | 2 ++
scripts/coccinelle/free/kfree.cocci | 18 +++---
scripts/coccinelle/free/kfreeaddr.cocci | 6 +-
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/scripts/coccinelle/free/devm_free.cocci
b/scripts/coccinelle/free/devm_free.cocci
index 3d9349012bb3..83c03adec1c5 100644
--- a/scripts/coccinelle/free/devm_free.cocci
+++ b/scripts/coccinelle/free/devm_free.cocci
@@ -48,6 +48,8 @@ position p;
(
* kfree@p(x)
|
+* kzfree@p(x)
+|
* free_irq@p(x)
|
* iounmap@p(x)
diff --git a/scripts/coccinelle/free/kfree.cocci
b/scripts/coccinelle/free/kfree.cocci
index 577b78056990..ac438da4fd7b 100644
--- a/scripts/coccinelle/free/kfree.cocci
+++ b/scripts/coccinelle/free/kfree.cocci
@@ -20,7 +20,11 @@ expression E;
position p1;
@@
-kfree@p1(E)
+(
+* kfree@p1(E)
+|
+* kzfree@p1(E)
+)
@print expression@
constant char [] c;
@@ -60,7 +64,11 @@ position ok;
@@
while (1) { ...
- kfree@ok(E)
+(
+* kfree@ok(E)
+|
+* kzfree@ok(E)
+)
... when != break;
when != goto l;
when forall
@@ -74,7 +82,11 @@ statement S;
position free.p1!=loop.ok,p2!={print.p,sz.p};
@@
-kfree@p1(E,...)
+(
+* kfree@p1(E,...)
+|
+* kzfree@p1(E,...)
+)
...
(
iter(...,subE,...) S // no use
diff --git a/scripts/coccinelle/free/kfreeaddr.cocci
b/scripts/coccinelle/free/kfreeaddr.cocci
index ce8aacc314cb..d46063b1db8b 100644
--- a/scripts/coccinelle/free/kfreeaddr.cocci
+++ b/scripts/coccinelle/free/kfreeaddr.cocci
@@ -16,7 +16,11 @@ identifier f;
position p;
@@
+(
* kfree@p(&e->f)
+|
+* kzfree@p(&e->f)
+)
@script:python depends on org@
p << r.p;
@@ -28,5 +32,5 @@ cocci.print_main("kfree",p)
p << r.p;
@@
-msg = "ERROR: kfree of structure field"
+msg = "ERROR: invalid free of structure field"
coccilib.report.print_report(p[0],msg)
--
2.5.0
Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915
Am 2016-02-22 um 11:34 schrieb Takashi Iwai: > On Mon, 22 Feb 2016 11:24:05 +0100, > Martin Kepplinger wrote: >> >> Am 2016-02-12 um 17:16 schrieb Takashi Iwai: >>> On Fri, 12 Feb 2016 16:54:44 +0100, >>> Martin Kepplinger wrote: Am 2016-02-12 um 14:49 schrieb Takashi Iwai: > On Fri, 12 Feb 2016 14:09:36 +0100, > Martin Kepplinger wrote: >> >> Am 2016-02-11 um 10:06 schrieb Takashi Iwai: >>> On Wed, 10 Feb 2016 18:21:11 +0100, >>> Martin Kepplinger wrote: Am 2016-02-09 um 12:44 schrieb Takashi Iwai: > On Tue, 09 Feb 2016 07:34:48 +0100, > Martin Kepplinger wrote: >> >> The following change: >> >> 788d441 ALSA: hda - Use component ops for i915 HDMI/DP audio jack >> handling >> >> breaks audio over HDMI on my snd_hda_intel laptop. It is the first >> bad >> commit. >> >> This was merged for -rc1 and isn't fixed until now, so I got nervous. >> There are >> no errors in the log that stand out. I'm no sound or alsa developer, >> and >> just reverting it isn't easy since there is stuff depending on this. >> >> I'm happy to test possible fixes and hope v4.5 not to ship with such >> a big >> regression ;) > > Could you give a bit more detail about your hardware? At best, give > alsa-info.sh output (run with --no-upload option). Also, give the > output of dmesg, too. > > In addition, what shows /proc/asound/card*/eld#*.* files? Does any of > it show the proper connection state and ELD? alsa-info and dmesg are appended, and root@laptop:/home/martin/dev# cat /proc/asound/card*/eld#* monitor_present0 eld_valid 0 >>> >>> OK, then could you put some debug print in intel_pin_eld_notify() in >>> sound/pci/hda/patch_hdmi.c? This is the callback to be called by i915 >>> driver at enabling / disabling HDMI/DP audio. >> >> intel_pin_eld_notify() is called during HDMI plugin with >> >> audio_ptr: 880242ea8800, port 1 >> >> and doesn't return early. > > OK, so it was processed but the ELD wasn't updated by some reason. > >>> (Also, to be sure, check whether snd_hdac_i915_register_notifier() in >>> sound/hda/hda_i915.c is called, too.) >> >> snd_hdac_i915_register_notifier() is called during boot. >> >>> >>> If intel_pin_eld_notify() is registered but never called, it implies >>> something wrong in i915 driver side. If it gets called, we need to >>> track down: what port value was passed there, and how >>> hdmi_present_sense() and sync_eld_via_acomp() behave there. >> >> I'll try to look at said path, if you have no other idea in the meantime. > > Put some debug prints in sync_eld_via_acomp(), e.g. check whether > snd_hdac_acomp_get_eld() returns an error or snd_hdmi_parse_eld() > returns an error. If you got an error, track down more deeply. > > For example, the former function is defined in sound/hda/hdac_i915.c, > and it calls the function i915_audio_component_get_eld() in > drivers/gpu/drm/i915/intel_audio.c. You can follow what returns an > error. > > Similarly, the latter function is defined in sound/pci/hda/hda_eld.c. > Usually you see a kernel message for parse errors, so I guess this > isn't the case, though. > no error in either of the functions. size is always 0, after boot and after HDMI plugin. is that normal? >>> >>> No, it means that no connection is reported back. Check the call of >>> i915_audio_component_get_eld() as mentioned in the above. >>> Does it return 0? Also I suppose monitor_present is set to false? >>> If so, it implies that intel_audio_codec_enable() isn't called. >>> >>> When the above is true, boot with drm.debug=0x0e, and give the kernel >>> messages. >>> >> >> The above is true and -rc5 didn't fix the problem. I append "dmesg|grep >> drm" with drm.debug=0x0e. HDMI is plugged in at about 90 seconds in. > > And how about my questions in the previous mail? Does > i915_audio_component_get_eld() is called and returns 0? > And is monitor_present set true or false? i915_audio_component_get_eld() returns 0 and monitor_present is 0. > > If i915_audio_component_get_eld() is called but returns zero, track > the code flow there. It means either intel_encoder is NULL or > intel_dig_port->audio_connector is NULL. intel_dig_port->audio_connector is NULL! (when called during boot and during HDMI plugin) I'll follow it more, but I'm just posting in case anyone finds the mistake early. thanks! > > > Takashi >
Re: [PATCH V4 5/6] perf/amd/iommu: Enable support for multiple IOMMUs
On Mon, Feb 22, 2016 at 03:00:31PM +0700, Suravee Suthikulpanit wrote: > >So I really don't have time to review new muck while I'm hunting perf > >core fail, but Boris made me look at this. > > > >This is crazy, if you have multiple IOMMUs then create an event per > >IOMMU, do _NOT_ fold them all into a single event. > > These are system-wide events, which are programmed on every IOMMU the same > way. I am not sure what you meant by creating an event per IOMMU. Do you > mean I should create internal per-IOMMU struct perf_event for each event? No, I meant to expose each IOMMU individually to userspace, as a separate device. Is there never a case to profile just one of the IOMMUs ?
Re: [PATCH] Doc: spi: make xmldocs warning caused by spi.c
On Mon, Feb 22, 2016 at 08:33:44PM +0900, Masanari Iida wrote: > This patch fix following warnings while make xmldocs. > > .//drivers/spi/spi.c:2354: warning: Excess function parameter > 'message' description in 'spi_split_transfers_maxsize' > .//drivers/spi/spi.c:2354: warning: Excess function parameter > 'max_size' description in 'spi_split_transfers_maxsize' Please use subject lines matching the style for the subsystem. This makes it easier for people to identify relevant patches. signature.asc Description: PGP signature
Re: [PATCH 0/6] Support for systems without AArch32 state
On 28/01/16 11:32, Suzuki K Poulose wrote: This series add checks to make sure that the AArch32 state is supported before we process the 32bit ID registers. Also checks the same for COMPAT binary execution. Yuri, Could you please give this series a spin on your hardware ? I don't have access to system where I can test this. Thanks Suzuki
Re: [PATCH] ALSA: mts64: use new parport device model
On Mon, 22 Feb 2016 14:22:08 +0100,
Sudip Mukherjee wrote:
>
> Modify mts64 driver to use the new parallel port device model.
> The advantage of using the device model is that the driver gets binded
> to the hardware, we get the feature of hotplug, we can bind/unbind the
> driver at runtime.
> The changes are in the way the driver gets registered with the parallel
> port subsystem and the temporary device to probe mts64 card is removed
> and mts64_probe() is used in the probe callback.
>
> Signed-off-by: Sudip Mukherjee
> ---
>
> exactly same changes as done in portman2x4.
Thanks, it looks like a nice cleanup. Applied now.
> BTW, there is one portman2x4 available on ebay. I was bidding for it but
> someone is more desperate than I am and outbidding me everytime :(
It's surprising that such a hardware is still beloved! :)
Good luck!
Takashi
> sound/drivers/mts64.c | 95
> +++
> 1 file changed, 43 insertions(+), 52 deletions(-)
>
> diff --git a/sound/drivers/mts64.c b/sound/drivers/mts64.c
> index 2a008a9..c76bd87 100644
> --- a/sound/drivers/mts64.c
> +++ b/sound/drivers/mts64.c
> @@ -65,8 +65,6 @@ struct mts64 {
> struct snd_card *card;
> struct snd_rawmidi *rmidi;
> struct pardevice *pardev;
> - int pardev_claimed;
> -
> int open_count;
> int current_midi_output_port;
> int current_midi_input_port;
> @@ -850,30 +848,6 @@ __out:
> spin_unlock(&mts->lock);
> }
>
> -static int snd_mts64_probe_port(struct parport *p)
> -{
> - struct pardevice *pardev;
> - int res;
> -
> - pardev = parport_register_device(p, DRIVER_NAME,
> - NULL, NULL, NULL,
> - 0, NULL);
> - if (!pardev)
> - return -EIO;
> -
> - if (parport_claim(pardev)) {
> - parport_unregister_device(pardev);
> - return -EIO;
> - }
> -
> - res = mts64_probe(p);
> -
> - parport_release(pardev);
> - parport_unregister_device(pardev);
> -
> - return res;
> -}
> -
> static void snd_mts64_attach(struct parport *p)
> {
> struct platform_device *device;
> @@ -907,10 +881,20 @@ static void snd_mts64_detach(struct parport *p)
> /* nothing to do here */
> }
>
> +static int snd_mts64_dev_probe(struct pardevice *pardev)
> +{
> + if (strcmp(pardev->name, DRIVER_NAME))
> + return -ENODEV;
> +
> + return 0;
> +}
> +
> static struct parport_driver mts64_parport_driver = {
> - .name = "mts64",
> - .attach = snd_mts64_attach,
> - .detach = snd_mts64_detach
> + .name = "mts64",
> + .probe = snd_mts64_dev_probe,
> + .match_port = snd_mts64_attach,
> + .detach = snd_mts64_detach,
> + .devmodel = true,
> };
>
> /*
> @@ -922,8 +906,7 @@ static void snd_mts64_card_private_free(struct snd_card
> *card)
> struct pardevice *pardev = mts->pardev;
>
> if (pardev) {
> - if (mts->pardev_claimed)
> - parport_release(pardev);
> + parport_release(pardev);
> parport_unregister_device(pardev);
> }
>
> @@ -938,6 +921,12 @@ static int snd_mts64_probe(struct platform_device *pdev)
> struct snd_card *card = NULL;
> struct mts64 *mts = NULL;
> int err;
> + struct pardev_cb mts64_cb = {
> + .preempt = NULL,
> + .wakeup = NULL,
> + .irq_func = snd_mts64_interrupt,/* ISR */
> + .flags = PARPORT_DEV_EXCL, /* flags */
> + };
>
> p = platform_get_drvdata(pdev);
> platform_set_drvdata(pdev, NULL);
> @@ -946,8 +935,6 @@ static int snd_mts64_probe(struct platform_device *pdev)
> return -ENODEV;
> if (!enable[dev])
> return -ENOENT;
> - if ((err = snd_mts64_probe_port(p)) < 0)
> - return err;
>
> err = snd_card_new(&pdev->dev, index[dev], id[dev], THIS_MODULE,
> 0, &card);
> @@ -960,23 +947,32 @@ static int snd_mts64_probe(struct platform_device *pdev)
> sprintf(card->longname, "%s at 0x%lx, irq %i",
> card->shortname, p->base, p->irq);
>
> - pardev = parport_register_device(p, /* port */
> - DRIVER_NAME, /* name */
> - NULL,/* preempt */
> - NULL,/* wakeup */
> - snd_mts64_interrupt, /* ISR */
> - PARPORT_DEV_EXCL,/* flags */
> - (void *)card); /* private */
> - if (pardev == NULL) {
> + mts64_cb.private = card; /* private */
> + pardev = parport_re
[RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB mappings
Currently, the memremap code serves MEMREMAP_WB mappings directly from
the kernel direct mapping, unless the region is in high memory, in which
case it falls back to using ioremap_cache(). However, the semantics of
ioremap_cache() are not unambiguously defined, and on ARM, it will
actually result in a mapping type that differs from the attributes used
for the linear mapping, and for this reason, the ioremap_cache() call
fails if the region is part of the memory managed by the kernel.
So instead, implement an optional hook 'arch_memremap_wb' whose default
implementation calls ioremap_cache() as before, but which can be
overridden by the architecture to do what is appropriate for it.
Cc: Dan Williams
Signed-off-by: Ard Biesheuvel
---
kernel/memremap.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 7a1b5c3ef14e..77c41648ba16 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -27,6 +27,13 @@ __weak void __iomem *ioremap_cache(resource_size_t offset,
unsigned long size)
}
#endif
+#ifndef arch_memremap_wb
+static void *arch_memremap_wb(resource_size_t offset, unsigned long size)
+{
+ return (__force void *)ioremap_cache(offset, size);
+}
+#endif
+
static void *try_ram_remap(resource_size_t offset, size_t size)
{
struct page *page = pfn_to_page(offset >> PAGE_SHIFT);
@@ -34,7 +41,7 @@ static void *try_ram_remap(resource_size_t offset, size_t
size)
/* In the simple case just return the existing linear address */
if (!PageHighMem(page))
return __va(offset);
- return NULL; /* fallback to ioremap_cache */
+ return arch_memremap_wb(offset, size);
}
/**
@@ -80,8 +87,6 @@ void *memremap(resource_size_t offset, size_t size, unsigned
long flags)
*/
if (is_ram == REGION_INTERSECTS)
addr = try_ram_remap(offset, size);
- if (!addr)
- addr = ioremap_cache(offset, size);
}
/*
--
2.5.0
[RFC PATCH 2/2] ARM: memremap: implement arch_memremap_wb()
The generic memremap() falls back to using ioremap_cache() to create
MEMREMAP_WB mappings if the requested region is not already covered
by the linear mapping, unless the architecture provides an implementation
of arch_memremap_wb().
Since ioremap_cache() is not appropriate on ARM to map memory with the
same attributes used for the linear mapping, implement arch_memremap_wb()
which does exactly that. Also, relax the WARN() check to allow MT_MEMORY_RW
mappings of pfn_valid() pages.
Cc: Russell King
Signed-off-by: Ard Biesheuvel
---
arch/arm/include/asm/io.h | 3 +++
arch/arm/mm/ioremap.c | 11 +--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 485982084fe9..7456638e6b3a 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -402,6 +402,9 @@ void __iomem *ioremap_wc(resource_size_t res_cookie, size_t
size);
void iounmap(volatile void __iomem *iomem_cookie);
#define iounmap iounmap
+void *arch_memremap_wb(phys_addr_t phys_addr, size_t size);
+#define arch_memremap_wb arch_memremap_wb
+
/*
* io{read,write}{16,32}be() macros
*/
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index 66a978d05958..d3a2b028c614 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -297,9 +297,10 @@ static void __iomem * __arm_ioremap_pfn_caller(unsigned
long pfn,
}
/*
-* Don't allow RAM to be mapped - this causes problems with ARMv6+
+* Don't allow RAM to be mapped with mismatched attributes - this
+* causes problems with ARMv6+
*/
- if (WARN_ON(pfn_valid(pfn)))
+ if (WARN_ON(pfn_valid(pfn) && mtype != MT_MEMORY_RW))
return NULL;
area = get_vm_area_caller(size, VM_IOREMAP, caller);
@@ -414,6 +415,12 @@ __arm_ioremap_exec(phys_addr_t phys_addr, size_t size,
bool cached)
__builtin_return_address(0));
}
+void *arch_memremap_wb(phys_addr_t phys_addr, size_t size)
+{
+ return __arm_ioremap_caller(phys_addr, size, MT_MEMORY_RW,
+ __builtin_return_address(0));
+}
+
void __iounmap(volatile void __iomem *io_addr)
{
void *addr = (void *)(PAGE_MASK & (unsigned long)io_addr);
--
2.5.0
[RFC PATCH 0/2] fix memremap on ARM
This is something I ran into while working on support for the UEFI memory attributes and ESRT tables. In both cases, these tables are passed to the kernel in memory which is guaranteed to be below 4 GB, but may be outside of the kernel direct mapping. (UEFI typically attempts to allocate from the top down, which means such tables are highly likely to be in highmem for any system with more than 760 MB of system RAM) The recently introduced memremap() is a very useful abstraction for accessing such tables, because it is generic, and already attempts to do the right thing with respect to regions that may already have been mapped directly. However, it falls back to ioremap_cache() for mapping high memory, which is not allowed on ARM. So instead, create an arch specific hook 'arch_memremap_wb(), and implement it for ARM using the same memory attributes used for the linear mapping. Note that memremap will only call this hook for regions that are not already mapped permanently. Ard Biesheuvel (2): memremap: add arch specific hook for MEMREMAP_WB mappings ARM: memremap: implement arch_memremap_wb() arch/arm/include/asm/io.h | 3 +++ arch/arm/mm/ioremap.c | 11 +-- kernel/memremap.c | 11 --- 3 files changed, 20 insertions(+), 5 deletions(-) -- 2.5.0
[PATCH 1/8] arm64: move acpi/dt decision earlier in boot process
From: Leif Lindholm
In order to support selecting earlycon via either ACPI or DT, move
the decision on whether to attempt ACPI configuration into the
early_param handling. Then make acpi_boot_table_init() bail out if
acpi_disabled.
Signed-off-by: Leif Lindholm
---
arch/arm64/kernel/acpi.c | 54 ++--
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..7a944f7 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -44,6 +44,19 @@ EXPORT_SYMBOL(acpi_pci_disabled);
static bool param_acpi_off __initdata;
static bool param_acpi_force __initdata;
+static int __init dt_scan_depth1_nodes(unsigned long node,
+ const char *uname, int depth,
+ void *data)
+{
+ /*
+* Return 1 as soon as we encounter a node at depth 1 that is
+* not the /chosen node.
+*/
+ if (depth == 1 && (strcmp(uname, "chosen") != 0))
+ return 1;
+ return 0;
+}
+
static int __init parse_acpi(char *arg)
{
if (!arg)
@@ -57,23 +70,27 @@ static int __init parse_acpi(char *arg)
else
return -EINVAL; /* Core will print when we return error */
- return 0;
-}
-early_param("acpi", parse_acpi);
+ /*
+* Enable ACPI instead of device tree unless
+* - ACPI has been disabled explicitly (acpi=off), or
+* - the device tree is not empty (it has more than just a /chosen node)
+* and ACPI has not been force enabled (acpi=force)
+*/
+ if (param_acpi_off ||
+ (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
+ return 0;
-static int __init dt_scan_depth1_nodes(unsigned long node,
- const char *uname, int depth,
- void *data)
-{
/*
-* Return 1 as soon as we encounter a node at depth 1 that is
-* not the /chosen node.
+* ACPI is disabled at this point. Enable it in order to parse
+* the ACPI tables and carry out sanity checks
*/
- if (depth == 1 && (strcmp(uname, "chosen") != 0))
- return 1;
+ enable_acpi();
+
return 0;
}
+early_param("acpi", parse_acpi);
+
/*
* __acpi_map_table() will be called before page_init(), so early_ioremap()
* or early_memremap() should be called here to for ACPI table mapping.
@@ -181,23 +198,10 @@ out:
*/
void __init acpi_boot_table_init(void)
{
- /*
-* Enable ACPI instead of device tree unless
-* - ACPI has been disabled explicitly (acpi=off), or
-* - the device tree is not empty (it has more than just a /chosen node)
-* and ACPI has not been force enabled (acpi=force)
-*/
- if (param_acpi_off ||
- (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
+ if (acpi_disabled)
return;
/*
-* ACPI is disabled at this point. Enable it in order to parse
-* the ACPI tables and carry out sanity checks
-*/
- enable_acpi();
-
- /*
* If ACPI tables are initialized and FADT sanity checks passed,
* leave ACPI enabled and carry on booting; otherwise disable ACPI
* on initialization error.
--
2.7.1
Re: [PATCH] kernel/resource.c: fix muxed resource handling in __request_region()
> we have some good alternatives in the form of bus and platform > drivers that > can manage the appropriate serialization and keep things from > stomping > on one another. It's not used much, especially nowdays. The use case is basically multi I/O chips on the ISA/LPC bus with magic shared config register ports. We have sufficiently few of those we could give muxed the boot and special case them if preferred. Alan
[PATCH 0/8] ACPI: parse the DBG2 table
ARM Server Base Boot Requiremets' [1] mentions DBG2 (Microsoft Debug Port Table 2) [2] as a mandatory ACPI table that specifies debug ports. - Move acpi/dt decision earlier in boot process on ARM64 - Move earlycon early_param handling to serial to parse earlycon option once - Add definition of DBG2 subtypes. It's the same patch as in the SPCR series [3] - Refactor ACPI linker tables code to enable iterating over subtables other than subtables having acpi_subtype header (such as DBG2) - Implement macros ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr) that defines a handler for the port of the given type and subtype. - For each port defined by that macros that is also described in the ACPI DBG2 table call provided callback. - Implement a helper macros that can be used to define early serial console - Enable DBG2 on ARM64 - Define early console for pl011 serial [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html [2] http://go.microsoft.com/fwlink/p/?LinkId=234837 [3] https://lkml.kernel.org/g/49532-8305-1-git-send-email-aleksey.maka...@linaro.org Aleksey Makarov (6): ACPI: add definitions of DBG2 subtypes ACPI: genaralize iterating over subtables in ACPI_PROBE_TABLE() ACPI: parse DBG2 table ACPI: serial: implement earlycon on ACPI DBG2 port ACPI: enable ACPI_DBG2_TABLE on ARM64 serial: pl011: add ACPI DBG2 serial port Leif Lindholm (2): arm64: move acpi/dt decision earlier in boot process of/serial: move earlycon early_param handling to serial Documentation/kernel-parameters.txt | 3 + arch/arm64/Kconfig | 1 + arch/arm64/kernel/acpi.c | 56 ++- drivers/acpi/Kconfig | 3 + drivers/acpi/Makefile| 1 + drivers/acpi/dbg2.c | 85 drivers/acpi/scan.c | 44 ++- drivers/clocksource/arm_arch_timer.c | 3 +- drivers/irqchip/irq-gic.c| 4 +- drivers/of/fdt.c | 11 +--- drivers/tty/serial/amba-pl011.c | 3 + drivers/tty/serial/earlycon.c| 57 +++ include/acpi/actbl2.h| 5 ++ include/asm-generic/vmlinux.lds.h| 1 + include/linux/acpi.h | 104 --- include/linux/acpi_dbg2.h| 68 +++ include/linux/clocksource.h | 2 +- include/linux/irqchip.h | 5 +- include/linux/of_fdt.h | 2 + 19 files changed, 370 insertions(+), 88 deletions(-) create mode 100644 drivers/acpi/dbg2.c create mode 100644 include/linux/acpi_dbg2.h -- 2.7.1
[PATCH 3/8] ACPI: add definitions of DBG2 subtypes
The recent version of Microsoft Debug Port Table 2 (DBG2) [1]
specifies additional serial debug port subtypes. These constants
are also referred by Serial Port Console Redirection Table (SPCR) [2]
Add these constants.
[1]
https://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
[2]
https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx
Signed-off-by: Aleksey Makarov
---
include/acpi/actbl2.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index a4ef625..652f747 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -371,6 +371,11 @@ struct acpi_dbg2_device {
#define ACPI_DBG2_16550_COMPATIBLE 0x
#define ACPI_DBG2_16550_SUBSET 0x0001
+#define ACPI_DBG2_ARM_PL011 0x0003
+#define ACPI_DBG2_ARM_SBSA_32BIT0x000D
+#define ACPI_DBG2_ARM_SBSA_GENERIC 0x000E
+#define ACPI_DBG2_ARM_DCC 0x000F
+#define ACPI_DBG2_BCM2835 0x0010
#define ACPI_DBG2_1394_STANDARD 0x
--
2.7.1
[PATCH 5/8] ACPI: parse DBG2 table
'ARM Server Base Boot Requiremets' [1] mentions DBG2 (Microsoft Debug
Port Table 2) [2] as a mandatory ACPI table that specifies debug ports.
- Implement macros
ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr)
that defines a handler for the port of given type and subtype.
- For each declared port that is also described in the ACPI DBG2 table
call the provided callback.
[1]
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[2] http://go.microsoft.com/fwlink/p/?LinkId=234837
Signed-off-by: Aleksey Makarov
---
drivers/acpi/Kconfig | 3 ++
drivers/acpi/Makefile | 1 +
drivers/acpi/dbg2.c | 85 +++
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/acpi_dbg2.h | 48 ++
5 files changed, 138 insertions(+)
create mode 100644 drivers/acpi/dbg2.c
create mode 100644 include/linux/acpi_dbg2.h
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 65fb483..660666e 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -57,6 +57,9 @@ config ACPI_SYSTEM_POWER_STATES_SUPPORT
config ACPI_CCA_REQUIRED
bool
+config ACPI_DBG2_TABLE
+ bool
+
config ACPI_DEBUGGER
bool "AML debugger interface"
select ACPI_DEBUG
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 346101c..ff5e4f0 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
obj-$(CONFIG_ACPI_BGRT)+= bgrt.o
obj-$(CONFIG_ACPI_CPPC_LIB)+= cppc_acpi.o
obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
+obj-$(CONFIG_ACPI_DBG2_TABLE) += dbg2.o
# processor has its own "processor." module_param namespace
processor-y:= processor_driver.o
diff --git a/drivers/acpi/dbg2.c b/drivers/acpi/dbg2.c
new file mode 100644
index 000..8a79117
--- /dev/null
+++ b/drivers/acpi/dbg2.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (c) 2012, Intel Corporation
+ * Copyright (c) 2015, 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#define pr_fmt(fmt) "ACPI: DBG2: " fmt
+
+#include
+#include
+#include
+
+static const char * __init type2string(u16 type)
+{
+ switch (type) {
+ case ACPI_DBG2_SERIAL_PORT:
+ return "SERIAL";
+ case ACPI_DBG2_1394_PORT:
+ return "1394";
+ case ACPI_DBG2_USB_PORT:
+ return "USB";
+ case ACPI_DBG2_NET_PORT:
+ return "NET";
+ default:
+ return "?";
+ }
+}
+
+static const char * __init subtype2string(u16 subtype)
+{
+ switch (subtype) {
+ case ACPI_DBG2_16550_COMPATIBLE:
+ return "16550_COMPATIBLE";
+ case ACPI_DBG2_16550_SUBSET:
+ return "16550_SUBSET";
+ case ACPI_DBG2_ARM_PL011:
+ return "ARM_PL011";
+ case ACPI_DBG2_ARM_SBSA_32BIT:
+ return "ARM_SBSA_32BIT";
+ case ACPI_DBG2_ARM_SBSA_GENERIC:
+ return "ARM_SBSA_GENERIC";
+ case ACPI_DBG2_ARM_DCC:
+ return "ARM_DCC";
+ case ACPI_DBG2_BCM2835:
+ return "BCM2835";
+ default:
+ return "?";
+ }
+}
+
+int __init acpi_dbg2_setup(struct acpi_table_header *table, const void *data)
+{
+ struct acpi_table_dbg2 *dbg2 = (struct acpi_table_dbg2 *)table;
+ struct acpi_dbg2_data *dbg2_data = (struct acpi_dbg2_data *)data;
+ struct acpi_dbg2_device *dbg2_device, *dbg2_end;
+ int i;
+
+ dbg2_device = ACPI_ADD_PTR(struct acpi_dbg2_device, dbg2,
+ dbg2->info_offset);
+ dbg2_end = ACPI_ADD_PTR(struct acpi_dbg2_device, dbg2, table->length);
+
+ for (i = 0; i < dbg2->info_count; i++) {
+ if (dbg2_device + 1 > dbg2_end) {
+ pr_err("device pointer overflows, bad table\n");
+ return 0;
+ }
+
+ if (dbg2_device->port_type == dbg2_data->port_type &&
+ dbg2_device->port_subtype == dbg2_data->port_subtype) {
+ pr_info("debug port type: %s subtype: %s\n",
+ type2string(dbg2_device->port_type),
+ subtype2string(dbg2_device->port_subtype));
+ dbg2_data->setup(dbg2_device, dbg2_data->data);
+ }
+
+ dbg2_device = ACPI_ADD_PTR(struct acpi_dbg2_device, dbg2_device,
+ dbg2_device->length);
+ }
+
+ return 0;
+}
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index c4bd0e2..ad9752c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@
[PATCH 6/8] ACPI: serial: implement earlycon on ACPI DBG2 port
Add ACPI_DBG2_EARLYCON_DECLARE() macros that declares
an earlycon on the serial port specified in the DBG2 ACPI table.
Pass the string "earlycon=acpi_dbg2" to the kernel to activate it.
Callbacks for EARLYCON_DECLARE() and OF_EARLYCON_DECLARE()
can also be used for this macros.
Signed-off-by: Aleksey Makarov
---
Documentation/kernel-parameters.txt | 3 ++
drivers/tty/serial/earlycon.c | 56 +
include/linux/acpi_dbg2.h | 20 +
3 files changed, 79 insertions(+)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 9a53c92..4949ebb 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1058,6 +1058,9 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
A valid base address must be provided, and the serial
port must already be setup and configured.
+ acpi_dbg2
+ Use serial port specified by the DBG2 ACPI table.
+
earlyprintk=[X86,SH,BLACKFIN,ARM,M68k]
earlyprintk=vga
earlyprintk=efi
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 05f9e4b..3d11248 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_FIX_EARLYCON_MEM
#include
@@ -186,6 +187,8 @@ int __init setup_earlycon(char *buf)
return -ENOENT;
}
+static bool setup_dbg2_earlycon;
+
/* early_param wrapper for setup_earlycon() */
static int __init param_setup_earlycon(char *buf)
{
@@ -198,6 +201,11 @@ static int __init param_setup_earlycon(char *buf)
if (!buf || !buf[0])
return early_init_dt_scan_chosen_serial();
+ if (!strcmp(buf, "acpi_dbg2")) {
+ setup_dbg2_earlycon = true;
+ return 0;
+ }
+
err = setup_earlycon(buf);
if (err == -ENOENT || err == -EALREADY)
return 0;
@@ -228,3 +236,51 @@ int __init of_setup_earlycon(unsigned long addr,
register_console(early_console_dev.con);
return 0;
}
+
+int __init acpi_setup_earlycon(struct acpi_dbg2_device *device, void *d)
+{
+ int err;
+ struct uart_port *port = &early_console_dev.port;
+ int (*setup)(struct earlycon_device *, const char *) = d;
+ struct acpi_generic_address *reg;
+
+ if (!setup_dbg2_earlycon)
+ return -ENODEV;
+
+ if (device->register_count < 1)
+ return -ENODEV;
+
+ if (device->base_address_offset >= device->length)
+ return -EINVAL;
+
+ reg = (void *)device + device->base_address_offset;
+
+ if (reg->space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY &&
+ reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO)
+ return -EINVAL;
+
+ spin_lock_init(&port->lock);
+ port->uartclk = BASE_BAUD * 16;
+
+ if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
+ if (device->port_type == ACPI_DBG2_ARM_SBSA_32BIT)
+ port->iotype = UPIO_MEM32;
+ else
+ port->iotype = UPIO_MEM;
+ port->mapbase = reg->address;
+ port->membase = earlycon_map(reg->address, SZ_4K);
+ } else {
+ port->iotype = UPIO_PORT;
+ port->iobase = reg->address;
+ }
+
+ early_console_dev.con->data = &early_console_dev;
+ err = setup(&early_console_dev, NULL);
+ if (err < 0)
+ return err;
+ if (!early_console_dev.con->write)
+ return -ENODEV;
+
+ register_console(early_console_dev.con);
+ return 0;
+}
diff --git a/include/linux/acpi_dbg2.h b/include/linux/acpi_dbg2.h
index 465afcb..9b96de2 100644
--- a/include/linux/acpi_dbg2.h
+++ b/include/linux/acpi_dbg2.h
@@ -37,12 +37,32 @@ int acpi_dbg2_setup(struct acpi_table_header *header, const
void *data);
ACPI_DECLARE_PROBE_ENTRY(dbg2, name, ACPI_SIG_DBG2, \
acpi_dbg2_setup, &__acpi_dbg2_data_##name)
+int __init acpi_setup_earlycon(struct acpi_dbg2_device *device, void *d);
+
+/*
+ * ACPI_DBG2_EARLYCON_DECLARE() - Define handler for ACPI GDB2 serial port
+ * @name: Identifier to compose name of table data
+ * @subtype: Subtype of the port
+ * @console_setup: Function to be called to setup the port
+ *
+ * Type of the console_setup() callback is
+ * int (*setup)(struct earlycon_device *, const char *)
+ * It's the type of callback of of_setup_earlycon().
+ */
+#define ACPI_DBG2_EARLYCON_DECLARE(name, subtype, console_setup) \
+ ACPI_DBG2_DECLARE(name, ACPI_DBG2_SERIAL_PORT, subtype, \
+ acpi_setup_earlycon, console_setup)
+
#else
#define ACPI_DBG2_DECLARE(name, type, subtype, setup_fn
[PATCH 7/8] ACPI: enable ACPI_DBG2_TABLE on ARM64
SBBR mentions DBG2 as a mandatory ACPI table. So enable it for ARM64 Signed-off-by: Aleksey Makarov --- arch/arm64/Kconfig | 1 + arch/arm64/kernel/acpi.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 6bb21d8..27cb5d7 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -3,6 +3,7 @@ config ARM64 select ACPI_CCA_REQUIRED if ACPI select ACPI_GENERIC_GSI if ACPI select ACPI_REDUCED_HARDWARE_ONLY if ACPI + select ACPI_DBG2_TABLE if ACPI select ARCH_HAS_DEVMEM_IS_ALLOWED select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select ARCH_HAS_ELF_RANDOMIZE diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index 7a944f7..890d36f 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -213,6 +213,8 @@ void __init acpi_boot_table_init(void) if (!param_acpi_force) disable_acpi(); } + + acpi_probe_device_table(dbg2); } #ifdef CONFIG_ACPI_APEI -- 2.7.1
[PATCH 4/8] ACPI: genaralize iterating over subtables in ACPI_PROBE_TABLE()
Refactor ACPI_PROBE_TABLE() so that it is possible to iterate
over subtables that do not have acpi_subtype header (for example
over subtables of DBG2 table)
To do so:
- Add void * data pointer argument for callback. It will allow to
parse the table and iterate over subtables calling the subtable
callbacks that are provided via this data pointer.
- Save only ACPI table id, callback and callback data in the linker
tables. This makes tables more terse and simplifies the semantics
of the fields of it's elements.
The additional data that required for subtable parsing are saved
in static namespace without increasing the size of linker tables.
- Introduce two macros with clear meaning of arguments, instead one.
The old ACPI_DECLARE_PROBE_ENTRY() macros has arguments that have
different meaning if the entry is for table or for subtable. The
arguments of the new macroses ACPI_DECLARE_PROBE_ENTRY() and
ACPI_DECLARE_PROBE_SUBTYPE_ENTRY() have unambiguous meaning.
- Document arguments of those macroses instead of the fields of linker
table data.
- Fix the issue that prevents using this macros for parsing subtables
other than MADT. In the original code, MADT-specific function
was used to iterate over subtables, while the name was common.
Introduce a new parameter to macors that specifies the size of
the table to do it in common way.
- Don't expose the internals of the tables to the drivers passing
a pointer to struct acpi_probe_entry to the subtable callback validator.
Instead, pass the sideband data specified by the driver.
- Fix the driver's callback signatures: a. Add an unused pointer to void
for table matchers (currently only clocksource callback) b. Change
the type of sideband data to kernel_ulong_t.
Signed-off-by: Aleksey Makarov
---
drivers/acpi/scan.c | 44 ++-
drivers/clocksource/arm_arch_timer.c | 3 +-
drivers/irqchip/irq-gic.c| 4 +-
include/linux/acpi.h | 104 ---
include/linux/clocksource.h | 2 +-
include/linux/irqchip.h | 5 +-
6 files changed, 109 insertions(+), 53 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 407a376..a258594 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1968,16 +1968,38 @@ static struct acpi_probe_entry *ape;
static int acpi_probe_count;
static DEFINE_SPINLOCK(acpi_probe_lock);
-static int __init acpi_match_madt(struct acpi_subtable_header *header,
- const unsigned long end)
+static int __init acpi_match_and_setup(struct acpi_subtable_header *header,
+ const unsigned long end)
{
- if (!ape->subtable_valid || ape->subtable_valid(header, ape))
- if (!ape->probe_subtbl(header, end))
+ const struct acpi_probe_subtype_data *data = ape->data;
+
+ if (data->valid(header, data->data))
+ if (!data->setup(header, end))
acpi_probe_count++;
return 0;
}
+int __init acpi_probe_subtype_setup(struct acpi_table_header *table,
+ const void *data)
+{
+ const struct acpi_probe_subtype_data *data_subtype = data;
+
+ return acpi_parse_entries(ape->id, data_subtype->size,
+ acpi_match_and_setup, table,
+ data_subtype->subtype, 0);
+}
+
+static int __init acpi_probe_table_handler(struct acpi_table_header *table)
+{
+ int err = ape->setup(table, ape->data);
+
+ if (ape->setup != acpi_probe_subtype_setup && err >= 0)
+ acpi_probe_count++;
+
+ return err;
+}
+
int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int nr)
{
int count = 0;
@@ -1987,16 +2009,10 @@ int __init __acpi_probe_device_table(struct
acpi_probe_entry *ap_head, int nr)
spin_lock(&acpi_probe_lock);
for (ape = ap_head; nr; ape++, nr--) {
- if (ACPI_COMPARE_NAME(ACPI_SIG_MADT, ape->id)) {
- acpi_probe_count = 0;
- acpi_table_parse_madt(ape->type, acpi_match_madt, 0);
- count += acpi_probe_count;
- } else {
- int res;
- res = acpi_table_parse(ape->id, ape->probe_table);
- if (!res)
- count++;
- }
+ acpi_probe_count = 0;
+ if (acpi_table_parse(ape->id, acpi_probe_table_handler) < 0)
+ continue;
+ count += acpi_probe_count;
}
spin_unlock(&acpi_probe_lock);
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index c64d543..95c4922e 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -826,7 +826,8 @@ static int __init map_generic_timer_int
[PATCH 8/8] serial: pl011: add ACPI DBG2 serial port
Add a handler for ACPI DBG2 serial port of type ACPI_DBG2_ARM_PL011 that sets up an earlycon on it. Signed-off-by: Aleksey Makarov --- drivers/tty/serial/amba-pl011.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c index c0da0cc..5633741 100644 --- a/drivers/tty/serial/amba-pl011.c +++ b/drivers/tty/serial/amba-pl011.c @@ -59,6 +59,7 @@ #include #include #include +#include #include "amba-pl011.h" @@ -2329,6 +2330,8 @@ static int __init pl011_early_console_setup(struct earlycon_device *device, } EARLYCON_DECLARE(pl011, pl011_early_console_setup); OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup); +ACPI_DBG2_EARLYCON_DECLARE(pl011, ACPI_DBG2_ARM_PL011, + pl011_early_console_setup); #else #define AMBA_CONSOLE NULL -- 2.7.1
[PATCH 2/8] of/serial: move earlycon early_param handling to serial
From: Leif Lindholm
We have multiple "earlycon" early_param handlers - merge the DT one into
the main earlycon one. This means the earlycon early_param handler does
not just return success if no options are specified.
Signed-off-by: Leif Lindholm
---
drivers/of/fdt.c | 11 +--
drivers/tty/serial/earlycon.c | 3 ++-
include/linux/of_fdt.h| 2 ++
3 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..6b4ab4f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -798,7 +798,7 @@ static inline void early_init_dt_check_for_initrd(unsigned
long node)
#ifdef CONFIG_SERIAL_EARLYCON
extern struct of_device_id __earlycon_of_table[];
-static int __init early_init_dt_scan_chosen_serial(void)
+int __init early_init_dt_scan_chosen_serial(void)
{
int offset;
const char *p;
@@ -843,15 +843,6 @@ static int __init early_init_dt_scan_chosen_serial(void)
}
return -ENODEV;
}
-
-static int __init setup_of_earlycon(char *buf)
-{
- if (buf)
- return 0;
-
- return early_init_dt_scan_chosen_serial();
-}
-early_param("earlycon", setup_of_earlycon);
#endif
/**
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 3f24236..05f9e4b 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -195,7 +196,7 @@ static int __init param_setup_earlycon(char *buf)
* don't generate a warning from parse_early_params() in that case
*/
if (!buf || !buf[0])
- return 0;
+ return early_init_dt_scan_chosen_serial();
err = setup_earlycon(buf);
if (err == -ENOENT || err == -EALREADY)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..4d783aa8 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -63,6 +63,7 @@ extern int early_init_dt_scan_chosen(unsigned long node,
const char *uname,
int depth, void *data);
extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
int depth, void *data);
+extern int early_init_dt_scan_chosen_serial(void);
extern void early_init_fdt_scan_reserved_mem(void);
extern void early_init_fdt_reserve_self(void);
extern void early_init_dt_add_memory_arch(u64 base, u64 size);
@@ -91,6 +92,7 @@ extern void early_get_first_memblock_info(void *, phys_addr_t
*);
extern u64 fdt_translate_address(const void *blob, int node_offset);
extern void of_fdt_limit_memory(int limit);
#else /* CONFIG_OF_FLATTREE */
+static inline int early_init_dt_scan_chosen_serial(void) { return -ENODEV; }
static inline void early_init_fdt_scan_reserved_mem(void) {}
static inline void early_init_fdt_reserve_self(void) {}
static inline const char *of_flat_dt_get_machine_name(void) { return NULL; }
--
2.7.1
Re: [PATCH v3 4/5] ACPI / processor_idle : introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE
Hi Rafael, On 17/02/16 12:21, Sudeep Holla wrote: On 16/02/16 20:18, Rafael J. Wysocki wrote: [..] This way it all should work without any new Kconfig options. I agree with you in terms of avoiding new Kconfig option. However the main reason for adding it is to avoid declaring dummy functions and variables on ARM64. It's hard to justify the maintainers as it's totally useless on ARM64. E.g. boot_option_idle_override, IDLE_NOMWAIT, acpi_unlazy_tlb, arch_safe_halt. Other option is to push those under CONFIG_X86, but then I don't have much idea on what are all needed for IA64, so took an option that encapsulates everything under CSTATE feature Kconfig, which is not user visible and selected by archs supporting it by default. I am open to any other alternative. Whatever alternative methods I tried so far ended up much horrible than this. So any suggestions are much appreciated. -- Regards, Sudeep
[PATCH] of: alloc anywhere from memblock if range not specified
early_init_dt_alloc_reserved_memory_arch passes end as 0 to
__memblock_alloc_base, when limits are not specified. But
__memblock_alloc_base takes end value of 0 as MEMBLOCK_ALLOC_ACCESSIBLE
and limits the end to memblock.current_limit. This results in regions
never being placed in HIGHMEM area, for e.g. CMA.
Let __memblock_alloc_base allocate from anywhere in memory if limits are
not specified.
Acked-by: Marek Szyprowski
Signed-off-by: Vinayak Menon
---
drivers/of/of_reserved_mem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1a3556a..ed01c01 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -32,11 +32,13 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
phys_addr_t align, phys_addr_t start, phys_addr_t end, bool nomap,
phys_addr_t *res_base)
{
+ phys_addr_t base;
/*
* We use __memblock_alloc_base() because memblock_alloc_base()
* panic()s on allocation failure.
*/
- phys_addr_t base = __memblock_alloc_base(size, align, end);
+ end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
+ base = __memblock_alloc_base(size, align, end);
if (!base)
return -ENOMEM;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v2 1/2] cpufreq: governor: Fix race in dbs_update_util_handler()
On 22-02-16, 14:14, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > There is a scenario that may lead to undesired results in > dbs_update_util_handler(). Namely, if two CPUs sharing a policy > enter the funtion at the same time, pass the sample delay check > and then one of them is stalled until dbs_work_handler() (queued > up by the other CPU) clears the work counter, it may update the > work counter and queue up another work item prematurely. > > To prevent that from happening, use the observation that the CPU > queuing up a work item in dbs_update_util_handler() updates the > last sample time. This means that if another CPU was stalling after > passing the sample delay check and now successfully updated the work > counter as a result of the race described above, it will see the new > value of the last sample time which is different from what it used in > the sample delay check before. If that happens, the sample delay > check passed previously is not valid any more, so the CPU should not > continue. > > Fixes: f17cbb53783c (cpufreq: governor: Avoid atomic operations in hot paths) > Signed-off-by: Rafael J. Wysocki > --- > > Changes from v1: > - Typo in the changelog fixed. > - READ_ONCE() used instead of ACCESS_ONCE(). > - If the race is detected, return instead of looping. Acked-by: Viresh Kumar -- viresh
Re: [PATCH] rtc: Add an option to invalidate dates in 2038
On Mon, 22 Feb 2016 14:00:14 +0100 Alexandre Belloni wrote: . > But there are long lived products like cars, parking ticket machines, > insulin pumps, automated external defibrillators, home automation > controllers, point of sales, etc... Some of those may still be in use in > 22 years. And if so their vendors will have provided updates. Your "fix" doesn't help anything, it just means the user sees it fail in a different way. > I can also agree that systemd could be a bit more robust there but > you'll have to convince Lennart... That's a systemd problem. If their code isn't robust then the distributiosn will just have to keep patching it. The only problem that can actually be "fixed" is the case where it isn't 2038 yet and the user has a scrambled RTC. In that case your init tools need to be robust enough to handle the problem or use APIs that don't break. The kernel can't actually "fix" this because it never knows whether your userspace is sane or not. I'd argue btw that any code using timerfd_create with TFD_TIMER_ABSTIME and passing it a value that wraps the range permitted by that time representation *is* buggy. It's the applications responsibility to use values that are within the defined behavioural range of the function. Far more constructive would I think be to add a TFD_TIME64 flag to timerfd_create that allows the use of 64bit time in timerfd_*. Systemd can then adopt that safely even on 32bit legacy systems, while on 64bit TFD_TIME64 would presumably be 0 and the 64/32bit time structs would match. Alan
[PATCH] fpga manager: Add hardware dependency to Zynq driver
The Zynq FPGA manager driver serves no purpose on other architectures so hide it unless build-testing. Signed-off-by: Jean Delvare Cc: Alan Tull Cc: Moritz Fischer Cc: Michal Simek Cc: "Sören Brinkmann" --- Michal, Sören, I'm not sure if the driver is needed on ARCH_ZYNQMP too? drivers/fpga/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-4.5-rc5.orig/drivers/fpga/Kconfig 2016-01-11 00:01:32.0 +0100 +++ linux-4.5-rc5/drivers/fpga/Kconfig 2016-02-22 14:11:33.142068843 +0100 @@ -21,6 +21,7 @@ config FPGA_MGR_SOCFPGA config FPGA_MGR_ZYNQ_FPGA tristate "Xilinx Zynq FPGA" + depends on ARCH_ZYNQ || COMPILE_TEST help FPGA manager driver support for Xilinx Zynq FPGAs. -- Jean Delvare SUSE L3 Support
RE: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
Hi Wolfram, > > Regression and a fix is required on top of this series. So can I > > send a separate fix on top of this series ? > > Yes, do it like this. And please quote only relevant parts of a mail. Ok, will send a fix separately. Sorry for the noisy reply previously .. Regards, Sricharan
Re: [PATCH v4 4/5] arm64/perf: Enable PMCR long cycle counter bit
On Mon, Feb 22, 2016 at 01:45:14PM +0100, Jan Glauber wrote: > On Thu, Feb 18, 2016 at 05:34:28PM +, Will Deacon wrote: > > On Thu, Feb 18, 2016 at 05:50:13PM +0100, Jan Glauber wrote: > > > With the long cycle counter bit (LC) disabled the cycle counter is not > > > working on ThunderX SOC (ThunderX only implements Aarch64). > > > Also, according to documentation LC == 0 is deprecated. > > > > > > To keep the code simple the patch does not introduce 64 bit wide counter > > > functions. Instead writing the cycle counter always sets the upper > > > 32 bits so overflow interrupts are generated as before. > > > > > > Original patch from Andrew Pinksi > > > > What does this mean? Do we need Andrew's S-o-B, or is this a fresh patch? > > Please let me know if I should repost or not, FWIW I got Andrew's S-o-B on the > patch. I think it's fine. This should all be in -next as of last Friday anyhow. Will
Re: [Xen-devel] [PATCH] xen-netfront: set real_num_tx_queues to zreo avoid to trigger BUG_ON
On 20/02/16 06:00, Gonglei (Arei) wrote: > Hi, > > Thanks for rapid feedback :) > >> From: David Miller [mailto:da...@davemloft.net] >> Sent: Saturday, February 20, 2016 12:37 PM >> >> From: Gonglei >> Date: Sat, 20 Feb 2016 09:27:26 +0800 >> >>> It's possible for a race condition to exist between xennet_open() and >>> talk_to_netback(). After invoking netfront_probe() then other >>> threads or processes invoke xennet_open (such as NetworkManager) >>> immediately may trigger BUG_ON(). Besides, we also should reset >>> real_num_tx_queues in xennet_destroy_queues(). >> >> One should really never invoke register_netdev() until the device is >> %100 fully initialized. >> >> This means you cannot call register_netdev() until it is completely >> legal to invoke your ->open() method. >> >> And I think that is what the real problem is here. >> >> If you follow the correct rules for ordering wrt. register_netdev() >> there are no "races". Because ->open() must be legally invokable >> from the exact moment you call register_netdev(). >> > > Yes, I agree. Though that's the historic legacy problem. ;) > >> I'm not applying this, as it really sounds like the fundamental issue >> is the order in which the xen-netfront private data is initialized >> or setup before being registered. > > That means register_netdev() should be invoked after xennet_connect(), right? No. This would mean that the network device is removed and re-added when a guest is migrated which at best would result in considerably more downtime (e.g., the IP address has to be renegotiated with DHCP). David
Re: [PATCH 1/2] cpufreq: governor: Fix race in dbs_update_util_handler()
On Mon, Feb 22, 2016 at 2:04 PM, Viresh Kumar wrote:
> On 22-02-16, 13:26, Rafael J. Wysocki wrote:
>> On Mon, Feb 22, 2016 at 6:23 AM, Viresh Kumar
>> wrote:
>> > On 21-02-16, 03:14, Rafael J. Wysocki wrote:
>> >> From: Rafael J. Wysocki
[cut]
>> > I think we should be doing this here:
>> >
>> > delta_ns = time - ACCESS_ONCE(policy_dbs->last_sample_time);
>> > if ((s64)delta_ns < policy_dbs->sample_delay_ns) {
>> > atomic_set(&policy_dbs->work_count, 0);
>> > return;
>> > }
>> >
>> > There is no point running the routine again, we already have ->work_count
>> > incremented for us, lets do the check right now.
>>
>> No, we need to check work_in_progress too.
>
> Then maybe move first half of this routine into a separate function
> and call it from the beginning and here ?
That won't help. The time value is still going to be stale.
Thanks,
Rafael
Re: 4.4.1 skb_warn_bad_offload+0xc5/0x110
[full-quote for netdev] Hello, On 16.02.2016 01:08, Wakko Warner wrote: Please keep me in CC. I've been seeing the following on some of my VMs ran under qemu. The VMs do not have internet connectivity. This happened when some files were accessed via NFS to another VM (NOTE: Both VMs throw these warnings. Both VMs are running the exact same kernel). The host is also throwing these warnings and is also 4.4.1, but not the same kernel build. The issue appears to have gone away if I issue the following on the guests and on the host (except br0 instead of eth0 on host) ethtool -K eth0 gso off gro off ufo off tso off On the host, br0 does not have any interfaces enslaved except for the interface for the VMs and also does not have an IPv4 address assigned. [ 90.067519] [ cut here ] [ 90.067678] WARNING: CPU: 0 PID: 2258 at /usr/src/linux/dist/4.4.1-nobklcd/net/core/dev.c:2422 skb_warn_bad_offload+0xc5/0x110() [ 90.067766] virtio_net: caps=(0x0804001f4a29, 0x) len=32934 data_len=32768 gso_size=1480 gso_type=2 ip_summed=0 [ 90.067878] Modules linked in: nfsv3 nfsd auth_rpcgss oid_registry exportfs nfs lockd grace sunrpc ipv6 virtio_net virtio_balloon evdev unix [ 90.068206] CPU: 0 PID: 2258 Comm: kworker/0:1H Not tainted 4.4.1 #1 [ 90.068258] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Debian-1.8.2-1 04/01/2014 [ 90.068340] Workqueue: rpciod rpc_async_schedule [sunrpc] [ 90.068433] 81503288 811d455e 880276ffb9a0 81041343 [ 90.068575] 88007b85be00 880276ffb9f0 0002 880276f87aac [ 90.068725] 88027692c000 810413b7 81503498 0030 [ 90.068846] Call Trace: [ 90.06] [] ? dump_stack+0x47/0x69 [ 90.068967] [] ? warn_slowpath_common+0x73/0xa0 [ 90.069068] [] ? warn_slowpath_fmt+0x47/0x50 [ 90.069129] [] ? skb_warn_bad_offload+0xc5/0x110 [ 90.069191] [] ? __skb_gso_segment+0x71/0xc0 [ 90.069250] [] ? validate_xmit_skb.isra.119.part.120+0x100/0x290 [ 90.069314] [] ? lock_timer_base.isra.22+0x49/0x60 [ 90.069381] [] ? validate_xmit_skb_list+0x31/0x50 [ 90.069440] [] ? sch_direct_xmit+0x140/0x1e0 [ 90.069497] [] ? __dev_queue_xmit+0x1c8/0x490 [ 90.069555] [] ? ip_finish_output2+0x122/0x300 [ 90.069613] [] ? release_sock+0xfd/0x160 [ 90.069671] [] ? ip_output+0xb5/0xc0 [ 90.069720] [] ? ip_reply_glue_bits+0x50/0x50 [ 90.069784] [] ? prandom_u32+0x1b/0x30 [ 90.069833] [] ? ip_local_out+0x12/0x40 [ 90.069877] [] ? ip_send_skb+0x10/0x40 [ 90.069922] [] ? udp_send_skb+0x160/0x240 [ 90.069990] [] ? udp_push_pending_frames+0x34/0x50 [ 90.070050] [] ? udp_sendpage+0xe4/0x150 [ 90.070095] [] ? kernel_sendmsg+0x2a/0x40 [ 90.070164] [] ? xs_send_kvec+0x83/0x90 [sunrpc] [ 90.070223] [] ? inet_sendpage+0x93/0xe0 [ 90.070270] [] ? xs_sendpages+0x16f/0x1b0 [sunrpc] [ 90.070330] [] ? xs_udp_send_request+0x5e/0x100 [sunrpc] [ 90.070390] [] ? xprt_transmit+0x47/0x230 [sunrpc] [ 90.070449] [] ? call_transmit+0x175/0x220 [sunrpc] [ 90.070508] [] ? __rpc_execute+0x4b/0x290 [sunrpc] [ 90.070575] [] ? finish_task_switch+0x83/0x1b0 [ 90.070653] [] ? process_one_work+0x129/0x3f0 [ 90.070711] [] ? worker_thread+0x42/0x490 [ 90.070764] [] ? process_one_work+0x3f0/0x3f0 [ 90.070816] [] ? kthread+0xb8/0xd0 [ 90.070860] [] ? kthread_worker_fn+0x100/0x100 [ 90.070925] [] ? ret_from_fork+0x3f/0x70 [ 90.070974] [] ? kthread_worker_fn+0x100/0x100 [ 90.071035] ---[ end trace ffb4f8c2d24c1959 ]--- Can you try the following patch? --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -1233,6 +1233,9 @@ ssize_t ip_append_page(struct sock *sk, struct flowi4 *fl4, struct page *page, if (!skb) return -EINVAL; + if (skb->ip_summed != CHECKSUM_PARTIAL) + return -EINVAL; + cork->length += size; if ((size + skb->len > mtu) && (sk->sk_protocol == IPPROTO_UDP) && Thanks, Hannes
Re: [PATCH] MAINTAINERS: alpine: add a new maintainer and update the entry
Acked -by: Tsahee Zidenberg On 22 February 2016 at 15:22, Antoine Tenart wrote: > Add myself as a co-maintainer for the Alpine support. Also update the > entry to take in account Alpine ARM64 boards, Alpine ARM device trees > and Alpine-specific drivers. > > Signed-off-by: Antoine Tenart > --- > MAINTAINERS | 4 > 1 file changed, 4 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 30aca4aa5467..53c07990e0f2 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -938,8 +938,12 @@ N: meson[x68] > > ARM/Annapurna Labs ALPINE ARCHITECTURE > M: Tsahee Zidenberg > +M: Antoine Tenart > S: Maintained > F: arch/arm/mach-alpine/ > +F: arch/arm/boot/dts/alpine* > +F: arch/arm64/boot/dts/al/ > +F: drivers/*/*alpine* > > ARM/ATMEL AT91RM9200, AT91SAM9 AND SAMA5 SOC SUPPORT > M: Nicolas Ferre > -- > 2.7.1 >
[PATCH] MAINTAINERS: alpine: add a new maintainer and update the entry
Add myself as a co-maintainer for the Alpine support. Also update the entry to take in account Alpine ARM64 boards, Alpine ARM device trees and Alpine-specific drivers. Signed-off-by: Antoine Tenart --- MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 30aca4aa5467..53c07990e0f2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -938,8 +938,12 @@ N: meson[x68] ARM/Annapurna Labs ALPINE ARCHITECTURE M: Tsahee Zidenberg +M: Antoine Tenart S: Maintained F: arch/arm/mach-alpine/ +F: arch/arm/boot/dts/alpine* +F: arch/arm64/boot/dts/al/ +F: drivers/*/*alpine* ARM/ATMEL AT91RM9200, AT91SAM9 AND SAMA5 SOC SUPPORT M: Nicolas Ferre -- 2.7.1
[PATCH] ALSA: mts64: use new parport device model
Modify mts64 driver to use the new parallel port device model.
The advantage of using the device model is that the driver gets binded
to the hardware, we get the feature of hotplug, we can bind/unbind the
driver at runtime.
The changes are in the way the driver gets registered with the parallel
port subsystem and the temporary device to probe mts64 card is removed
and mts64_probe() is used in the probe callback.
Signed-off-by: Sudip Mukherjee
---
exactly same changes as done in portman2x4.
BTW, there is one portman2x4 available on ebay. I was bidding for it but
someone is more desperate than I am and outbidding me everytime :(
sound/drivers/mts64.c | 95 +++
1 file changed, 43 insertions(+), 52 deletions(-)
diff --git a/sound/drivers/mts64.c b/sound/drivers/mts64.c
index 2a008a9..c76bd87 100644
--- a/sound/drivers/mts64.c
+++ b/sound/drivers/mts64.c
@@ -65,8 +65,6 @@ struct mts64 {
struct snd_card *card;
struct snd_rawmidi *rmidi;
struct pardevice *pardev;
- int pardev_claimed;
-
int open_count;
int current_midi_output_port;
int current_midi_input_port;
@@ -850,30 +848,6 @@ __out:
spin_unlock(&mts->lock);
}
-static int snd_mts64_probe_port(struct parport *p)
-{
- struct pardevice *pardev;
- int res;
-
- pardev = parport_register_device(p, DRIVER_NAME,
-NULL, NULL, NULL,
-0, NULL);
- if (!pardev)
- return -EIO;
-
- if (parport_claim(pardev)) {
- parport_unregister_device(pardev);
- return -EIO;
- }
-
- res = mts64_probe(p);
-
- parport_release(pardev);
- parport_unregister_device(pardev);
-
- return res;
-}
-
static void snd_mts64_attach(struct parport *p)
{
struct platform_device *device;
@@ -907,10 +881,20 @@ static void snd_mts64_detach(struct parport *p)
/* nothing to do here */
}
+static int snd_mts64_dev_probe(struct pardevice *pardev)
+{
+ if (strcmp(pardev->name, DRIVER_NAME))
+ return -ENODEV;
+
+ return 0;
+}
+
static struct parport_driver mts64_parport_driver = {
- .name = "mts64",
- .attach = snd_mts64_attach,
- .detach = snd_mts64_detach
+ .name = "mts64",
+ .probe = snd_mts64_dev_probe,
+ .match_port = snd_mts64_attach,
+ .detach = snd_mts64_detach,
+ .devmodel = true,
};
/*
@@ -922,8 +906,7 @@ static void snd_mts64_card_private_free(struct snd_card
*card)
struct pardevice *pardev = mts->pardev;
if (pardev) {
- if (mts->pardev_claimed)
- parport_release(pardev);
+ parport_release(pardev);
parport_unregister_device(pardev);
}
@@ -938,6 +921,12 @@ static int snd_mts64_probe(struct platform_device *pdev)
struct snd_card *card = NULL;
struct mts64 *mts = NULL;
int err;
+ struct pardev_cb mts64_cb = {
+ .preempt = NULL,
+ .wakeup = NULL,
+ .irq_func = snd_mts64_interrupt,/* ISR */
+ .flags = PARPORT_DEV_EXCL, /* flags */
+ };
p = platform_get_drvdata(pdev);
platform_set_drvdata(pdev, NULL);
@@ -946,8 +935,6 @@ static int snd_mts64_probe(struct platform_device *pdev)
return -ENODEV;
if (!enable[dev])
return -ENOENT;
- if ((err = snd_mts64_probe_port(p)) < 0)
- return err;
err = snd_card_new(&pdev->dev, index[dev], id[dev], THIS_MODULE,
0, &card);
@@ -960,23 +947,32 @@ static int snd_mts64_probe(struct platform_device *pdev)
sprintf(card->longname, "%s at 0x%lx, irq %i",
card->shortname, p->base, p->irq);
- pardev = parport_register_device(p, /* port */
-DRIVER_NAME, /* name */
-NULL,/* preempt */
-NULL,/* wakeup */
-snd_mts64_interrupt, /* ISR */
-PARPORT_DEV_EXCL,/* flags */
-(void *)card); /* private */
- if (pardev == NULL) {
+ mts64_cb.private = card; /* private */
+ pardev = parport_register_dev_model(p, /* port */
+ DRIVER_NAME, /* name */
+ &mts64_cb, /* callbacks */
+ pdev->id); /* device number */
+ if (!pardev) {
snd_printd("Canno
Re: [PATCH] Doc: xtensa : Fix a typo in atomctl.txt
On Mon, 22 Feb 2016 20:41:54 +0900 Masanari Iida wrote: > -use the memory controllers RCW, thought non-MX controlers likely > +use the memory controllers RCW, thought non-MX controllers likely That's a good fix, but can I ask you to send a version that does s/thought/though/ while you're working on that line? Thanks, jon
[GIT PULL] xen: bug fixes for 4.5-rc5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.5-rc5-tag Xen bug fixes for 4.5-rc5 - - Two scsiback fixes (resource leak and spurious warning). - - Fix DMA mapping of compound pages on arm/arm64. - - Fix some pciback regressions in MSI-X handling. - - Fix a pcifront crash due to some uninitialize state. Thanks. David arch/arm/include/asm/xen/page-coherent.h | 21 ++--- arch/x86/include/asm/xen/pci.h | 4 +- arch/x86/pci/xen.c | 5 +- drivers/pci/xen-pcifront.c | 10 ++-- drivers/xen/xen-pciback/pciback_ops.c| 9 +++- drivers/xen/xen-scsiback.c | 80 ++-- drivers/xen/xenbus/xenbus_dev_frontend.c | 2 + 7 files changed, 81 insertions(+), 50 deletions(-) Ian Campbell (1): xen/arm: correctly handle DMA mapping of compound pages Insu Yun (1): xen: fix potential integer overflow in queue_reply Juergen Gross (2): xen/scsiback: correct frontend counting xen/scsiback: avoid warnings when adding multiple LUNs to a domain Konrad Rzeszutek Wilk (4): xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY xen/pciback: Save the number of MSI-X entries to be copied later. xen/pcifront: Report the errors better. xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWywq1AAoJEFxbo/MsZsTRdp0H/iq2sxOtCSXqytfV/XOau7As HCA7tHYkY/MEZ01I2uIajXfOoKrFRcSBoU3jCEYBbnu7gv5/jEwiGFDxgM4dw5bK eywUK5TF9il9byq1Ys/WJkuIYoeBC+VV8c7niStnEgr2R9TNMp66U6IMqPhqmCnK +6a3npuzJ+RckyNF3fMJOrgzuIqashUZ6ghdawRVcT+BKg6rAGriYIPHB22ek1fR K+dszjt6xKKT42nhHggWkINmV9Gmi23E7HrwuAqq+UiYMmBImJlwLnWMx9yLhh+r 0xpRdJKU4zaUAIOqNlVY6QwRfRY+Yvdh0HDoTog2Y4lDysT4fl0DGiHlpJRFaho= =vyvq -END PGP SIGNATURE-
Re: [PATCH] cpufreq: simplify for_each_suitable_policy() macro
On Monday, February 22, 2016 11:03:15 AM Viresh Kumar wrote:
> On 21-02-16, 12:53, Eric Biggers wrote:
> > Signed-off-by: Eric Biggers
> > ---
> > drivers/cpufreq/cpufreq.c | 44 +++-
> > 1 file changed, 3 insertions(+), 41 deletions(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index e979ec7..3aa7b2b 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -38,48 +38,10 @@ static inline bool policy_is_inactive(struct
> > cpufreq_policy *policy)
> > return cpumask_empty(policy->cpus);
> > }
> >
> > -static bool suitable_policy(struct cpufreq_policy *policy, bool active)
> > -{
> > - return active == !policy_is_inactive(policy);
> > -}
> > -
> > -/* Finds Next Acive/Inactive policy */
> > -static struct cpufreq_policy *next_policy(struct cpufreq_policy *policy,
> > - bool active)
> > -{
> > - do {
> > - /* No more policies in the list */
> > - if (list_is_last(&policy->policy_list, &cpufreq_policy_list))
> > - return NULL;
> > -
> > - policy = list_next_entry(policy, policy_list);
> > - } while (!suitable_policy(policy, active));
> > -
> > - return policy;
> > -}
> > -
> > -static struct cpufreq_policy *first_policy(bool active)
> > -{
> > - struct cpufreq_policy *policy;
> > -
> > - /* No policies in the list */
> > - if (list_empty(&cpufreq_policy_list))
> > - return NULL;
> > -
> > - policy = list_first_entry(&cpufreq_policy_list, typeof(*policy),
> > - policy_list);
> > -
> > - if (!suitable_policy(policy, active))
> > - policy = next_policy(policy, active);
> > -
> > - return policy;
> > -}
> > -
> > /* Macros to iterate over CPU policies */
> > -#define for_each_suitable_policy(__policy, __active) \
> > - for (__policy = first_policy(__active); \
> > -__policy; \
> > -__policy = next_policy(__policy, __active))
> > +#define for_each_suitable_policy(__policy, __active)
> > \
> > + list_for_each_entry(__policy, &cpufreq_policy_list, policy_list) \
> > + if ((__active) == !policy_is_inactive(__policy))
> >
> > #define for_each_active_policy(__policy) \
> > for_each_suitable_policy(__policy, true)
>
> Acked-by: Viresh Kumar
Queued up for 4.6, thanks!
Re: [PATCH] cpufreq: fix comment about return value of cpufreq_register_driver()
On Monday, February 22, 2016 10:54:46 AM Viresh Kumar wrote:
> On 20-02-16, 21:50, Eric Biggers wrote:
> > The comment has been incorrect since commit 4dea5806d332
> > ("cpufreq: return EEXIST instead of EBUSY for second registering").
> >
> > Signed-off-by: Eric Biggers
> > ---
> > drivers/cpufreq/cpufreq.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index e979ec7..bfefc91 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -2384,7 +2384,7 @@ EXPORT_SYMBOL_GPL(cpufreq_boost_enabled);
> > * submitted by the CPU Frequency driver.
> > *
> > * Registers a CPU Frequency driver to this core code. This code
> > - * returns zero on success, -EBUSY when another driver got here first
> > + * returns zero on success, -EEXIST when another driver got here first
> > * (and isn't unregistered in the meantime).
> > *
> > */
>
> Acked-by: Viresh Kumar
Queued up for 4.6, thanks!
[PATCH v2 1/2] cpufreq: governor: Fix race in dbs_update_util_handler()
From: Rafael J. Wysocki
There is a scenario that may lead to undesired results in
dbs_update_util_handler(). Namely, if two CPUs sharing a policy
enter the funtion at the same time, pass the sample delay check
and then one of them is stalled until dbs_work_handler() (queued
up by the other CPU) clears the work counter, it may update the
work counter and queue up another work item prematurely.
To prevent that from happening, use the observation that the CPU
queuing up a work item in dbs_update_util_handler() updates the
last sample time. This means that if another CPU was stalling after
passing the sample delay check and now successfully updated the work
counter as a result of the race described above, it will see the new
value of the last sample time which is different from what it used in
the sample delay check before. If that happens, the sample delay
check passed previously is not valid any more, so the CPU should not
continue.
Fixes: f17cbb53783c (cpufreq: governor: Avoid atomic operations in hot paths)
Signed-off-by: Rafael J. Wysocki
---
Changes from v1:
- Typo in the changelog fixed.
- READ_ONCE() used instead of ACCESS_ONCE().
- If the race is detected, return instead of looping.
---
drivers/cpufreq/cpufreq_governor.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -341,7 +341,7 @@ static void dbs_update_util_handler(stru
{
struct cpu_dbs_info *cdbs = container_of(data, struct cpu_dbs_info,
update_util);
struct policy_dbs_info *policy_dbs = cdbs->policy_dbs;
- u64 delta_ns;
+ u64 delta_ns, lst;
/*
* The work may not be allowed to be queued up right now.
@@ -357,7 +357,8 @@ static void dbs_update_util_handler(stru
* of sample_delay_ns used in the computation may be stale.
*/
smp_rmb();
- delta_ns = time - policy_dbs->last_sample_time;
+ lst = READ_ONCE(policy_dbs->last_sample_time);
+ delta_ns = time - lst;
if ((s64)delta_ns < policy_dbs->sample_delay_ns)
return;
@@ -366,9 +367,19 @@ static void dbs_update_util_handler(stru
* at this point. Otherwise, we need to ensure that only one of the
* CPUs sharing the policy will do that.
*/
- if (policy_dbs->is_shared &&
- !atomic_add_unless(&policy_dbs->work_count, 1, 1))
- return;
+ if (policy_dbs->is_shared) {
+ if (!atomic_add_unless(&policy_dbs->work_count, 1, 1))
+ return;
+
+ /*
+* If another CPU updated last_sample_time in the meantime, we
+* shouldn't be here, so clear the work counter and bail out.
+*/
+ if (unlikely(lst != READ_ONCE(policy_dbs->last_sample_time))) {
+ atomic_set(&policy_dbs->work_count, 0);
+ return;
+ }
+ }
policy_dbs->last_sample_time = time;
policy_dbs->work_in_progress = true;
[PATCH 2/2 v3] chrdev: allocate dynamic chardevs in all unused holes
This is a duct-tape-and-chewing-gum solution to the problem with the major numbers running out when allocating major numbers dynamically. To avoid collisions in the major space, we supply a bitmap with "holes" that exist in the lower range of major numbers [0-254] and pick numbers from there, beginning with the unused char device 8 and moving up through 26, 40, 60-63, 93-94, 102, 120-127, 159, 213-215, 222-223 and 234-254. It will also FAIL if we actually fill up all free major numbers. This seems to me like the reasonable thing to do since the other numbers are, after all, reserved. This also adds the macro BITS() to so we can define the static bitmap at compiletime in a reasonable way. If someone prefer that I just put opaque hex numbers in there, then tell me, that works too, it's just not elegant IMO. The macro with the same name in select.c is consequently renamed FDS_BITS(). This also deletes the comment /* temporary */ which must be one of the biggest lies ever. This also updates the Documentation/devices.txt document to reflect that all these numbers are used for dynamic assignment. Reported-by: Ying Huang Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: Alan Cox Cc: Arnd Bergmann Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Of course I had a dangling hunk for pr_dbg()->pr_debug() in my working tree. Mea culpa. - Fix the redefinition of BITS() in select.c to use the more precise name FDS_BITS() over the generic plural. ChangeLog v1->v2: - Follow-up on the previous RFC patch, this uses Torvald's suggested bitmap approach to allocate devices instead of a list of free numbers. - As a result of using find_first_zero_bit(), the major numbers are assigned from low to high instead from high to low. It's a bit scarier but I guess drivers using dynamic numbers should be all right with it, I'm more worried about userspaces expecting dynamic majors to be in the [234,254] range. Input welcome, maybe I'm just chicken. - This still needs to be applied on top of the previous fix to start warning about going below major 234. If you prefer to just get this patch and get rid of the problem then tell me. --- Documentation/devices.txt | 22 ++ fs/char_dev.c | 46 ++ fs/select.c | 6 +++--- include/linux/bitops.h| 1 + include/linux/fs.h| 2 -- 5 files changed, 52 insertions(+), 25 deletions(-) diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 4035eca87144..2a4242be2fcd 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -248,6 +248,8 @@ Your cooperation is appreciated. associated with block devices. The binding to the loop devices is handled by mount(8) or losetup(8). + 8 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS + 8 block SCSI disk devices (0-15) 0 = /dev/sda First SCSI disk whole disk 16 = /dev/sdb Second SCSI disk whole disk @@ -620,7 +622,7 @@ Your cooperation is appreciated. 2 = /dev/sbpcd2 Panasonic CD-ROM controller 0 unit 2 3 = /dev/sbpcd3 Panasonic CD-ROM controller 0 unit 3 - 26 char + 26 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 26 block Second Matsushita (Panasonic/SoundBlaster) CD-ROM 0 = /dev/sbpcd4 Panasonic CD-ROM controller 1 unit 0 @@ -863,7 +865,7 @@ Your cooperation is appreciated. ... 39 block - 40 char + 40 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 40 block @@ -1127,7 +1129,7 @@ Your cooperation is appreciated. NAMING CONFLICT -- PROPOSED REVISED NAME /dev/rpda0 etc - 60-63 charLOCAL/EXPERIMENTAL USE + 60-63 charRESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 60-63 block LOCAL/EXPERIMENTAL USE Allocated for local/experimental use. For devices not @@ -1641,7 +1643,7 @@ Your cooperation is appreciated. disks (see major number 3) except that the limit on partitions is 15. - 93 char + 93 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 93 block NAND Flash Translation Layer filesystem 0 = /dev/nftlaFirst NFTL layer @@ -1649,7 +1651,7 @@ Your cooperation is appreciated. ... 240 = /dev/nftlp16th NTFL layer - 94 char + 94 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 94 block IBM S/390 DASD block storage 0 = /dev/dasda First DASD device, major @@ -1742,7 +1744,7 @@ Your cooperation is appreciated. ... 15 = /dev/amiraid/ar?p15 15th partition -102 char +102 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 102 block Compressed block device 0 = /dev/cbd/aFir
[PATCH v5 3/4] ARM: dts: sun8i-h3: Add R_PIO controller node to the dtsi
Add the corresponding device node for R_PIO on H3 to the dtsi. Support
for the controller was added in earlier commit.
Signed-off-by: Krzysztof Adamski
---
arch/arm/boot/dts/sun8i-h3.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 1348b69..c3b73d7 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -518,5 +518,17 @@
compatible = "allwinner,sun6i-a31-clock-reset";
#reset-cells = <1>;
};
+
+ r_pio: pinctrl@01f02c00 {
+ compatible = "allwinner,sun8i-h3-r-pinctrl";
+ reg = <0x01f02c00 0x400>;
+ interrupts = ;
+ clocks = <&apb0_gates 0>;
+ resets = <&apb0_reset 0>;
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
};
};
--
2.1.4
[PATCH v5 1/4] clk: sunxi: Add apb0 gates for H3
This patch adds support for APB0 in H3. It seems to be compatible with earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR, etc). Signed-off-by: Krzysztof Adamski --- Documentation/devicetree/bindings/clock/sunxi.txt | 2 ++ drivers/clk/sunxi/clk-simple-gates.c | 4 2 files changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index c09f59b..834436f 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -18,6 +18,7 @@ Required properties: "allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock "allwinner,sun4i-a10-axi-clk" - for the AXI clock "allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23 + "allwinner,sun4i-a10-gates-clk" - for generic gates on all compatible SoCs "allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates "allwinner,sun4i-a10-ahb-clk" - for the AHB clock "allwinner,sun5i-a13-ahb-clk" - for the AHB clock on A13 @@ -46,6 +47,7 @@ Required properties: "allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31 "allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20 "allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23 + "allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3 "allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80 "allwinner,sun4i-a10-apb1-clk" - for the APB1 clock "allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80 diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c index 2cfc5a8..d7ec2dc 100644 --- a/drivers/clk/sunxi/clk-simple-gates.c +++ b/drivers/clk/sunxi/clk-simple-gates.c @@ -98,6 +98,8 @@ static void __init sunxi_simple_gates_init(struct device_node *node) sunxi_simple_gates_setup(node, NULL, 0); } +CLK_OF_DECLARE(sun4i_a10_gates, "allwinner,sun4i-a10-gates-clk", + sunxi_simple_gates_init); CLK_OF_DECLARE(sun4i_a10_apb0, "allwinner,sun4i-a10-apb0-gates-clk", sunxi_simple_gates_init); CLK_OF_DECLARE(sun4i_a10_apb1, "allwinner,sun4i-a10-apb1-gates-clk", @@ -132,6 +134,8 @@ CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk", sunxi_simple_gates_init); CLK_OF_DECLARE(sun8i_a83t_apb0, "allwinner,sun8i-a83t-apb0-gates-clk", sunxi_simple_gates_init); +CLK_OF_DECLARE(sun8i_h3_apb0, "allwinner,sun8i-h3-apb0-gates-clk", + sunxi_simple_gates_init); CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk", sunxi_simple_gates_init); CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk", -- 2.1.4
[PATCH v5 4/4] ARM: dts: sun8i: Add leds and switch on Orangepi Plus boards
OrangePi Plus board has two leds - green ("pwr") and red ("status")
and a switch ("sw4"). This patch describes them in a devicetree.
Signed-off-by: Krzysztof Adamski
---
arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 63
1 file changed, 63 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
index e67df59..5f159d0 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
@@ -45,6 +45,7 @@
#include "sunxi-common-regulators.dtsi"
#include
+#include
#include
/ {
@@ -58,6 +59,68 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_opc>;
+
+ status_led {
+ label = "status:red:user";
+ gpios = <&pio 0 15 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ r_leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_r_opc>;
+
+ tx {
+ label = "pwr:green:user";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
+ r_gpio_keys {
+ compatible = "gpio-keys";
+ input-name = "sw4";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&sw_r_opc>;
+
+ sw4@0 {
+ label = "sw4";
+ linux,code = ;
+ gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&pio {
+ leds_opc: led_pins@0 {
+ allwinner,pins = "PA15";
+ allwinner,function = "gpio_out";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+};
+
+&r_pio {
+ leds_r_opc: led_pins@0 {
+ allwinner,pins = "PL10";
+ allwinner,function = "gpio_out";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
+
+ sw_r_opc: key_pins@0 {
+ allwinner,pins = "PL03";
+ allwinner,function = "gpio_in";
+ allwinner,drive = ;
+ allwinner,pull = ;
+ };
};
&mmc0 {
--
2.1.4
[PATCH v5 0/4] pinctrl: sunxi: Add H3 R_PIO controller support
This patch series is extension of my original single patch with the same subject. It adds support for R_PIO so that GPIO port L can be used in H3 based devices. It was tested on OrangePi PC and OrangePi Plus where PL is connected amount others to an onboard led, a switch, an IR receiver and some VCC controllers. Patchset is based on next-20160222. --- Changes since v4: - remove patches that are alredy merged - add patch describing leds and switch in DT Changes since v3: - collect some acked-bys - fix r_pios #interrupt-cells Changes since v2: - fixed apb0 parrent clocks list - moved binding documentation change to the proper patch - simplified sunxi_pinctrl_gpio_get according to ChenYu suggestions - fixed ordering in sunxi binding documentation Changes since v1: - splited patch to two separate - dtsi and c files - added APB0 clocks a parent for R_PIO - added fix in sunxi_pinctrl_gpio_get for getting pin value when in irq mode and on 2nd pinctrl - fixed a "pwn" > "pwm" typo - fixed order in allwinner,sunxi-pinctrl.txt Krzysztof Adamski (4): clk: sunxi: Add apb0 gates for H3 dts: sun8i-h3: Add APB0 related clocks and resets ARM: dts: sun8i-h3: Add R_PIO controller node to the dtsi ARM: dts: sun8i: Add leds and switch on Orangepi Plus boards Krzysztof Adamski (4): clk: sunxi: Add apb0 gates for H3 dts: sun8i-h3: Add APB0 related clocks and resets ARM: dts: sun8i-h3: Add R_PIO controller node to the dtsi ARM: dts: sun8i: Add leds and switch on Orangepi Plus boards Documentation/devicetree/bindings/clock/sunxi.txt | 2 + arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 63 +++ arch/arm/boot/dts/sun8i-h3.dtsi | 37 + drivers/clk/sunxi/clk-simple-gates.c | 4 ++ 4 files changed, 106 insertions(+) -- 2.1.4
[PATCH v5 2/4] dts: sun8i-h3: Add APB0 related clocks and resets
APB0 is bearly mentioned in H3 User Manual and it is only setup in the
Allwinners kernel dump for CIR. I have verified experimentally that the
gate for R_PIO exists and works, though. There are probably other gates
there but I don't know their order right now and I don't have access to
their peripherals on my board to test them.
After some experiments and reviewing how this is organized on other
sunxi SoCs, I couldn't actually find any way to disable clocks for R_PIO
and they are working properly without doing anything so I assume they
are connected straight to the 24Mhz oscillator for now.
Signed-off-by: Krzysztof Adamski
---
arch/arm/boot/dts/sun8i-h3.dtsi | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 3ba65c2..1348b69 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -276,6 +276,25 @@
clocks = <&osc24M>, <&pll6 1>, <&pll5>;
clock-output-names = "mbus";
};
+
+ apb0: apb0_clk {
+ compatible = "fixed-factor-clock";
+ #clock-cells = <0>;
+ clock-div = <1>;
+ clock-mult = <1>;
+ clocks = <&osc24M>;
+ clock-output-names = "apb0";
+ };
+
+ apb0_gates: clk@01f01428 {
+ compatible = "allwinner,sun8i-h3-apb0-gates-clk",
+"allwinner,sun4i-a10-gates-clk";
+ reg = <0x01f01428 0x4>;
+ #clock-cells = <1>;
+ clocks = <&apb0>;
+ clock-indices = <0>, <1>;
+ clock-output-names = "apb0_pio", "apb0_ir";
+ };
};
soc {
@@ -493,5 +512,11 @@
interrupts = ,
;
};
+
+ apb0_reset: reset@01f014b0 {
+ reg = <0x01f014b0 0x4>;
+ compatible = "allwinner,sun6i-a31-clock-reset";
+ #reset-cells = <1>;
+ };
};
};
--
2.1.4
Re: [PATCH 1/2] cpufreq: governor: Fix race in dbs_update_util_handler()
On 22-02-16, 13:26, Rafael J. Wysocki wrote:
> On Mon, Feb 22, 2016 at 6:23 AM, Viresh Kumar wrote:
> > On 21-02-16, 03:14, Rafael J. Wysocki wrote:
> >> From: Rafael J. Wysocki
> >>
> >> There is a scenarion that may lead to undesired results in
> >
> > scenario
> >
> >> dbs_update_util_handler(). Namely, if two CPUs sharing a policy
> >> enter the funtion at the same time, pass the sample delay check
> >> and then one of them is stalled until dbs_work_handler() (queued
> >> up by the other CPU) clears the work counter, it may update the
> >> work counter and queue up another work item prematurely.
> >>
> >> To prevent that from happening, use the observation that the CPU
> >> queuing up a work item in dbs_update_util_handler() updates the
> >> last sample time. This means that if another CPU was stalling after
> >> passing the sample delay check and now successfully updated the work
> >> counter as a result of the race described above, it will see the new
> >> value of the last sample time which is different from what it used in
> >> the sample delay check before. If that happens, the sample delay
> >> check passed previously is not valid any more, so the CPU should not
> >> continue, but leaving the funtion at that point might miss an
> >> opportunity to take the next sample, so simply clear the work
> >> counter and jump to the beginning of the function in that case.
> >>
> >> Fixes: f17cbb53783c (cpufreq: governor: Avoid atomic operations in hot
> >> paths)
> >> Signed-off-by: Rafael J. Wysocki
> >> ---
> >> drivers/cpufreq/cpufreq_governor.c | 22 +-
> >> 1 file changed, 17 insertions(+), 5 deletions(-)
> >>
> >> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> >> ===
> >> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> >> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> >> @@ -341,8 +341,9 @@ static void dbs_update_util_handler(stru
> >> {
> >> struct cpu_dbs_info *cdbs = container_of(data, struct cpu_dbs_info,
> >> update_util);
> >> struct policy_dbs_info *policy_dbs = cdbs->policy_dbs;
> >> - u64 delta_ns;
> >> + u64 delta_ns, lst;
> >>
> >> + start:
> >> /*
> >>* The work may not be allowed to be queued up right now.
> >>* Possible reasons:
> >> @@ -357,7 +358,8 @@ static void dbs_update_util_handler(stru
> >>* of sample_delay_ns used in the computation may be stale.
> >>*/
> >> smp_rmb();
> >> - delta_ns = time - policy_dbs->last_sample_time;
> >> + lst = ACCESS_ONCE(policy_dbs->last_sample_time);
> >
> > The comment on the top of ACCESS_ONCE() asks us to use READ_ONCE() if
> > possible.
>
> I forgot about this one, thanks!
>
> >> + delta_ns = time - lst;
> >> if ((s64)delta_ns < policy_dbs->sample_delay_ns)
> >> return;
> >>
> >> @@ -366,9 +368,19 @@ static void dbs_update_util_handler(stru
> >>* at this point. Otherwise, we need to ensure that only one of the
> >>* CPUs sharing the policy will do that.
> >>*/
> >> - if (policy_dbs->is_shared &&
> >> - !atomic_add_unless(&policy_dbs->work_count, 1, 1))
> >> - return;
> >> + if (policy_dbs->is_shared) {
> >> + if (!atomic_add_unless(&policy_dbs->work_count, 1, 1))
> >> + return;
> >> +
> >> + /*
> >> + * If another CPU updated last_sample_time in the meantime,
> >> we
> >> + * shouldn't be here, so clear the work counter and try
> >> again.
> >> + */
> >> + if (unlikely(lst !=
> >> ACCESS_ONCE(policy_dbs->last_sample_time))) {
> >> + atomic_set(&policy_dbs->work_count, 0);
> >> + goto start;
> >> + }
> >
> > I think we should be doing this here:
> >
> > delta_ns = time - ACCESS_ONCE(policy_dbs->last_sample_time);
> > if ((s64)delta_ns < policy_dbs->sample_delay_ns) {
> > atomic_set(&policy_dbs->work_count, 0);
> > return;
> > }
> >
> > There is no point running the routine again, we already have ->work_count
> > incremented for us, lets do the check right now.
>
> No, we need to check work_in_progress too.
Then maybe move first half of this routine into a separate function
and call it from the beginning and here ?
--
viresh
Re: [PATCH v2 3/3] vfs: Use per-cpu list for superblock's inode list
On Mon 22-02-16 13:12:22, Peter Zijlstra wrote:
> On Mon, Feb 22, 2016 at 12:54:35PM +0100, Jan Kara wrote:
> > > Also, I think fsnotify_unmount_inodes() (as per mainline) is missing a
> > > final iput(need_iput) at the very end, but I could be mistaken, that
> > > code hurts my brain.
> >
> > I think the code is actually correct since need_iput contains "inode
> > further in the list than the current inode". Thus we will always go though
> > another iteration of the loop which will drop the reference. And inode
> > cannot change state to I_FREEING or I_WILL_FREE because we hold inode
> > reference. But it is subtle as hell so I agree that code needs rewrite.
>
> So while talking to dchinner, he doubted fsnotify will actually remove
> inodes from the sb-list, but wasn't sure and too tired to check now.
>
> (I got lost in the fsnotify code real quick and gave up, for I was
> mostly trying to make a point that we don't need the CPP magic and can
> do with 'readable' code).
>
> If it doesn't, it doesn't need to do this extra special magic dance and
> can use the 'normal' iterator pattern used in all the other functions,
> greatly reducing complexity.
Yeah, that would be nice. But fsnotify code needs to iterate over all
inodes, drop sb_list_lock and do some fsnotify magic with the inode which
is not substantial for our discussion. Now that fsnotify magic may actually
drop all the remaining inode references so once we drop our reference
pinning the inode, it can just disappear. We don't want to restart the scan
for each inode we have to process so that is the reason why we play ugly
tricks with pinning the next inode in the list.
But I agree it should be possible to just use list_for_each_entry() instead
of list_for_each_entry_safe() and keep current inode pinned till the next
iteration to make it stick in the sb->s_inodes list. That would make the
iteration more standard. Lightly tested patch attached.
Honza
--
Jan Kara
SUSE Labs, CR
>From b73ae63fff14dea2afac34523d5ebfc5f030eff6 Mon Sep 17 00:00:00 2001
From: Jan Kara
Date: Mon, 22 Feb 2016 13:54:32 +0100
Subject: [PATCH] fsnotify: Simplify inode iteration on umount
fsnotify_unmount_inodes() played complex tricks to pin next inode in the
sb->s_inodes list when iterating over all inodes. If we switch to
keeping current inode pinned somewhat longer, we can make the code much
simpler and standard.
Signed-off-by: Jan Kara
---
fs/notify/inode_mark.c | 45 +
1 file changed, 9 insertions(+), 36 deletions(-)
diff --git a/fs/notify/inode_mark.c b/fs/notify/inode_mark.c
index 741077deef3b..a3645249f7ec 100644
--- a/fs/notify/inode_mark.c
+++ b/fs/notify/inode_mark.c
@@ -150,12 +150,10 @@ int fsnotify_add_inode_mark(struct fsnotify_mark *mark,
*/
void fsnotify_unmount_inodes(struct super_block *sb)
{
- struct inode *inode, *next_i, *need_iput = NULL;
+ struct inode *inode, *iput_inode = NULL;
spin_lock(&sb->s_inode_list_lock);
- list_for_each_entry_safe(inode, next_i, &sb->s_inodes, i_sb_list) {
- struct inode *need_iput_tmp;
-
+ list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
/*
* We cannot __iget() an inode in state I_FREEING,
* I_WILL_FREE, or I_NEW which is fine because by that point
@@ -178,49 +176,24 @@ void fsnotify_unmount_inodes(struct super_block *sb)
continue;
}
- need_iput_tmp = need_iput;
- need_iput = NULL;
-
- /* In case fsnotify_inode_delete() drops a reference. */
- if (inode != need_iput_tmp)
- __iget(inode);
- else
- need_iput_tmp = NULL;
+ __iget(inode);
spin_unlock(&inode->i_lock);
-
- /* In case the dropping of a reference would nuke next_i. */
- while (&next_i->i_sb_list != &sb->s_inodes) {
- spin_lock(&next_i->i_lock);
- if (!(next_i->i_state & (I_FREEING | I_WILL_FREE)) &&
- atomic_read(&next_i->i_count)) {
-__iget(next_i);
-need_iput = next_i;
-spin_unlock(&next_i->i_lock);
-break;
- }
- spin_unlock(&next_i->i_lock);
- next_i = list_next_entry(next_i, i_sb_list);
- }
-
- /*
- * We can safely drop s_inode_list_lock here because either
- * we actually hold references on both inode and next_i or
- * end of list. Also no new inodes will be added since the
- * umount has begun.
- */
spin_unlock(&sb->s_inode_list_lock);
- if (need_iput_tmp)
- iput(need_iput_tmp);
+ if (iput_inode)
+ iput(iput_inode);
/* for each watch, send FS_UNMOUNT and then remove it */
fsnotify(inode, FS_UNMOUNT, inode, FSNOTIFY_EVENT_INODE, NULL, 0);
fsnotify_inode_delete(inode);
- iput(inode);
+ iput_inode = inode;
spin_lock(&sb->s_inode_list_lock);
}
spin_unlock(&sb->s_inode_list_lock);
+
+ if (iput_inode)
+ iput(iput_inode);
}
--
2.6.2
Re: [PATCH] rtc: Add an option to invalidate dates in 2038
On 21/02/2016 at 12:40:20 +, One Thousand Gnomes wrote : > > It doesn't change anything for 64-bit systems, I've excluded them by > > using "depends on !64BIT". Right now, it doesn't change anything for > > 32-bit systems because either way, they will fail in 2038. > > Which realistically won't actually matter because in 22 years time nobody > will be able to find a 32bit system in common use. If you look at x86 > platforms today a Pentium Pro is already a collectors item. All of todays > locked down half-maintained embedded and phone devices will be at best > the digital equivalent of toxic waste if connected to anything. > The current 32 bit systems are not only phones. I'm not concerned by those, they have an average 18 month live and the manufacturers are already switching to 64 bit. But there are long lived products like cars, parking ticket machines, insulin pumps, automated external defibrillators, home automation controllers, point of sales, etc... Some of those may still be in use in 22 years. Or maybe we want to ensure that there is a Y2038 bug, that can be a good retirement plan for the whole IT industry ;) > > Won't we have to recompile every application to support 64-bit time on > > 32-bit system anyway? That will be a good time to remove that option. > > How will you know when everyone has ? There's no "autodetect which > distribution I am running" feature. > I have the hope that the distribution maintainers know how to configure a kernel and will ship a kernel with that option unset once they switched to a 64 bit time userspace. > > If the distribution don't recompile to support a 64-bit time, then the > > 32-bit systems will break in 2038 anyway and they will absolutely > > require my patch or something along those lines to still boot using > > systemd. > > I disagree. Systemd has a serious robustness bug. Patch systemd to handle > timerd going off early and to take appropriate recovery action. > > If you fix the systemd bug you'll also deal with a load of other weird > cornercases like 32bit guests on a 64bit host that accidentally ended up > post 2038, and every other freaky rtc failure. > Actually, I agree with Lennart that this is definitively a kernel bug that has to be fixed. systemd is not the only affected application, any user of timerfd is failing (actually, the first report I got was not related to systemd at all). I can also agree that systemd could be a bit more robust there but you'll have to convince Lennart... -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Re: [PATCH] ARM: at91: sama5/dts: move hsmc_clk out of nfc node
Le 17/02/2016 06:42, Wenyou Yang a écrit :
> From: Josh Wu
>
> In sama5d3, sama5d4 chips, pmecc will use the hsmc clock. As pmecc is
> part of HSMC. So move out hsmc_clk from nfc node to nand node.
>
> Signed-off-by: Josh Wu
> Signed-off-by: Wenyou Yang
I'm not against this change, but beware, it must be applied in
synchronization with the patch just posted "[PATCH] mtd: atmel_nand:
move the hsmc_clk from nfc node to nand node"
Bye,
> ---
>
> arch/arm/boot/dts/sama5d3.dtsi |2 +-
> arch/arm/boot/dts/sama5d4.dtsi |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index a532791..a242d27 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -1474,6 +1474,7 @@
> atmel,nand-has-dma;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_nand0_ale_cle>;
> + clocks = <&hsmc_clk>;
> atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
> status = "disabled";
>
> @@ -1486,7 +1487,6 @@
> 0xc000 0x0070 /* NFC HSMC
> regs */
> 0x0020 0x0010 /* NFC SRAM
> banks */
> >;
> - clocks = <&hsmc_clk>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
> index b8032bc..1499b33 100644
> --- a/arch/arm/boot/dts/sama5d4.dtsi
> +++ b/arch/arm/boot/dts/sama5d4.dtsi
> @@ -295,6 +295,7 @@
> atmel,nand-has-dma;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_nand>;
> + clocks = <&hsmc_clk>;
> status = "disabled";
>
> nfc@9000 {
> @@ -306,7 +307,6 @@
> 0xfc05c000 0x0070 /* NFC HSMC
> regs */
> 0x0010 0x0010 /* NFC SRAM
> banks */
> >;
> - clocks = <&hsmc_clk>;
> atmel,write-by-sram;
> };
> };
>
--
Nicolas Ferre
Re: [PATCH] mtd: atmel_nand: move the hsmc_clk from nfc node to nand node
Le 17/02/2016 06:40, Wenyou Yang a écrit :
> From: Josh Wu
>
> For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they
> need the HSMC clock to be enabled to work.
> The NFC is a sub feature for current nand driver, it can be disabled.
> But if HSMC clock is controlled by NFC, so disable NFC will also
> disable the HSMC clock. then, it will make the PMECC fail to work.
>
> So the solution is to move the HSMC clock out of NFC to nand node.
> When nand driver probed, it will check whether the chip has HSMC,
> if yes then it will require a HSMC clock.
>
> Signed-off-by: Josh Wu
> Signed-off-by: Wenyou Yang
> ---
>
> .../devicetree/bindings/mtd/atmel-nand.txt |4 +-
> drivers/mtd/nand/atmel_nand.c | 43
> +---
> 2 files changed, 22 insertions(+), 25 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> index d53aba9..29bee7c 100644
> --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> @@ -15,6 +15,7 @@ Required properties:
> - atmel,nand-cmd-offset : offset for the command latch.
> - #address-cells, #size-cells : Must be present if the device has sub-nodes
>representing partitions.
> +- clocks: phandle to the peripheral clock
>
> - gpios : specifies the gpio pins to control the NAND device. detect is an
>optional gpio and may be set to 0 if not present.
> @@ -43,7 +44,6 @@ Required properties:
> - reg : should specify the address and size used for NFC command registers,
> NFC registers and NFC SRAM. NFC SRAM address and size can be absent
> if don't want to use it.
> -- clocks: phandle to the peripheral clock
> Optional properties:
> - atmel,write-by-sram: boolean to enable NFC write by SRAM.
>
> @@ -100,13 +100,13 @@ nand0: nand@4000 {
> compatible = "atmel,at91rm9200-nand";
> #address-cells = <1>;
> #size-cells = <1>;
> + clocks = <&hsmc_clk>
> ranges;
> ...
> nfc@7000 {
> compatible = "atmel,sama5d3-nfc";
> #address-cells = <1>;
> #size-cells = <1>;
> - clocks = <&hsmc_clk>
> reg = <
> 0x7000 0x1000 /* NFC Command Registers */
> 0xc000 0x0070 /* NFC HSMC regs */
> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
> index 20cbaab..a1f4ad2 100644
> --- a/drivers/mtd/nand/atmel_nand.c
> +++ b/drivers/mtd/nand/atmel_nand.c
> @@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);
> struct atmel_nand_caps {
> bool pmecc_correct_erase_page;
> uint8_t pmecc_max_correction;
> + bool has_hsmc_clk;
> };
>
> struct atmel_nand_nfc_caps {
> @@ -106,8 +107,6 @@ struct atmel_nfc {
> booluse_nfc_sram;
> boolwrite_by_sram;
>
> - struct clk *clk;
> -
> boolis_initialized;
> struct completion comp_ready;
> struct completion comp_cmd_done;
> @@ -132,6 +131,7 @@ struct atmel_nand_host {
> struct dma_chan *dma_chan;
>
> struct atmel_nfc*nfc;
> + struct clk *clk;
>
> const struct atmel_nand_caps*caps;
> boolhas_pmecc;
> @@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device
> *pdev)
> nand_chip->IO_ADDR_R = host->io_base;
> nand_chip->IO_ADDR_W = host->io_base;
>
> + if (host->caps->has_hsmc_clk) {
> + host->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(host->clk)) {
> + dev_err(&pdev->dev, "HSMC clock is missing, update your
> Device Tree");
> + res = PTR_ERR(host->clk);
> + goto err_nand_ioremap;
> + }
> +
> + res = clk_prepare_enable(host->clk);
> + if (res)
> + goto err_nand_ioremap;
> + }
> +
> if (nand_nfc.is_initialized) {
> /* NFC driver is probed and initialized */
> host->nfc = &nand_nfc;
> @@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device
> *pdev)
> if (host->dma_chan)
> dma_release_channel(host->dma_chan);
>
> + if (!IS_ERR(host->clk))
> + clk_disable_unprepare(host->clk);
> +
> platform_driver_unregister(&atmel_nand_nfc_driver);
>
> return 0;
> @@ -2334,11 +2350,13 @@ static int atmel_nand_remove(struct platform_device
> *pdev)
> static const struct atmel_nand_caps at91rm9200_caps = {
> .pmecc_correct_erase_page = false,
> .pmecc_max_correction = 24,
> + .has_hsmc_clk = false,
> };
>
> static const struct atmel_nand_caps sama5d4_caps = {
> .pmecc_correct_erase_page = true,
> .pmecc_max_correction = 2
Re: [PATCH] intel-pstate: Update frequencies of policy->cpus only from ->set_policy()
On Mon, Feb 22, 2016 at 12:27 PM, Viresh Kumar wrote: > Hi, > > I am not really an intel-pstate driver guy, just wrote the patch based > on software-review of the stuff :) > > On 22-02-16, 10:17, Chen, Yu C wrote: >> IIRC, >> 1.HWP is hardwarely per-package, CPUs inside one package have one shared >> HWP. >> 2.Currently all the CPUs share the same HWP settings according to >> intel_pstate design. >> 3. The policy is per-cpu in intel_pstate driver.(policy->cpus only contains >> one cpu) >> >> So with this patch applied, it is likely CPUs may have different HWP >> settings? > > I think the hardware should be able to cope with that, and should be > selecting the frequency based on the highest frequency requested for > the same package. Otherwise, why should there be an option to supply > per-cpu settings ? Right. I can easily imagine a use case in which someone may want to have different ranges for different CPUs. >> For example: >> CPU 0 belongs to package A with policy 0, and CPU 1 belongs to package B >> with policy 1, >> If you change the policy 0 from powersave to performance, then only CPU0 >> will update its >> min/max freq in HWP, however we should also update CPU 2's min/max in HWP >> settings? >> Plz correct me if I'm wrong.. > > I will let the official intel-pstate guys reply to that. My opinion is to do what your patch does until that proves to be a problem in practice. Thanks, Rafael
Re: [PATCH v4 4/5] arm64/perf: Enable PMCR long cycle counter bit
On Thu, Feb 18, 2016 at 05:34:28PM +, Will Deacon wrote: > On Thu, Feb 18, 2016 at 05:50:13PM +0100, Jan Glauber wrote: > > With the long cycle counter bit (LC) disabled the cycle counter is not > > working on ThunderX SOC (ThunderX only implements Aarch64). > > Also, according to documentation LC == 0 is deprecated. > > > > To keep the code simple the patch does not introduce 64 bit wide counter > > functions. Instead writing the cycle counter always sets the upper > > 32 bits so overflow interrupts are generated as before. > > > > Original patch from Andrew Pinksi > > What does this mean? Do we need Andrew's S-o-B, or is this a fresh patch? Hi Will, Please let me know if I should repost or not, FWIW I got Andrew's S-o-B on the patch. Thanks, Jan > Will
Re: [PATCH v2 01/15] arm: use of_platform_default_populate() to populate default bus
Le 27/01/2016 08:53, Kefeng Wang a écrit : > diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c > index c1a7c6c..1904bc7 100644 > --- a/arch/arm/mach-at91/at91rm9200.c > +++ b/arch/arm/mach-at91/at91rm9200.c > @@ -31,7 +31,7 @@ static void __init at91rm9200_dt_device_init(void) > if (soc != NULL) > soc_dev = soc_device_to_device(soc); > > - of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev); > + of_platform_default_populate(NULL, NULL, soc_dev); > > arm_pm_idle = at91rm9200_idle; > at91rm9200_pm_init(); > diff --git a/arch/arm/mach-at91/at91sam9.c b/arch/arm/mach-at91/at91sam9.c > index 7eb64f7..d495620 100644 > --- a/arch/arm/mach-at91/at91sam9.c > +++ b/arch/arm/mach-at91/at91sam9.c > @@ -61,7 +61,7 @@ static void __init at91sam9_common_init(void) > if (soc != NULL) > soc_dev = soc_device_to_device(soc); > > - of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev); > + of_platform_default_populate(NULL, NULL, soc_dev); > > arm_pm_idle = at91sam9_idle; > } > diff --git a/arch/arm/mach-at91/sama5.c b/arch/arm/mach-at91/sama5.c > index d9cf679..6db395e 100644 > --- a/arch/arm/mach-at91/sama5.c > +++ b/arch/arm/mach-at91/sama5.c > @@ -50,7 +50,7 @@ static void __init sama5_dt_device_init(void) > if (soc != NULL) > soc_dev = soc_device_to_device(soc); > > - of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev); > + of_platform_default_populate(NULL, NULL, soc_dev); > at91sam9x5_pm_init(); > } For AT91: Acked-by: Nicolas Ferre Thanks, bye. -- Nicolas Ferre
Re: 4.5-rc4 kernel is failed to bootup on CN6880
Hi,
On Fri, Feb 19, 2016 at 05:12:41PM -0800, Yang Shi wrote:
> I tried to boot 4.5-rc4 kernel on my CN6880 board, but it is failed at
> booting up secondary cores. The error is:
With v4.5-rc5, EBB6800 is booting fine:
[0.00] CPU0 revision is: 000d9108 (Cavium Octeon II)
[...]
[ 2286.273935] SMP: Booting CPU01 (CoreId 1)...
[ 2286.278201] CPU1 revision is: 000d9108 (Cavium Octeon II)
[...]
[ 2287.214953] SMP: Booting CPU31 (CoreId 31)...
[ 2287.224668] CPU31 revision is: 000d9108 (Cavium Octeon II)
[ 2287.224865] Brought up 32 CPUs
> CPU31 revision is: 000d9101 (Cavium Octeon II)
> SMP: Booting CPU32 (CoreId 32)...
> Secondary boot timeout
>
> I passed "numcores=32" in kernel commandline since there are 32 cores ion
> CN6880.
You shouldn't have CPU32 in that case, the numbering starts from zero.
Also the coremask is 32-bit.
I can reproduce your issue with CONFIG_NR_CPUS=64. Possibly this code
is incorrect for NR_CPUS bigger than 32:
/* The present CPUs get the lowest CPU numbers. */
cpus = 1;
for (id = 0; id < NR_CPUS; id++) {
if ((id != coreid) && (core_mask & (1 << id))) {
set_cpu_possible(cpus, true);
set_cpu_present(cpus, true);
What CONFIG_NR_CPUS did you use?
A.
Re: [PATCH v4 3/5] arm64: dts: Add Cavium ThunderX specific PMU
On Thu, Feb 18, 2016 at 05:32:48PM +, Will Deacon wrote:
> On Thu, Feb 18, 2016 at 05:50:12PM +0100, Jan Glauber wrote:
> > Add a compatible string for the Cavium ThunderX PMU.
>
> Stupid question, but is "thunder" the name of the CPU or the SoC or ...?
>
> Whatever we use to describe the PMU, should probably also identify the
> CPU uniquely.
The CPU is currently:
compatible = "cavium,thunder", "arm,armv8";
We clearly need better names in case of a subsequent CPU, but for now
I think we should stick to the existing name.
Jan
> Will
>
> > Signed-off-by: Jan Glauber
> > ---
> > Documentation/devicetree/bindings/arm/pmu.txt | 1 +
> > arch/arm64/boot/dts/cavium/thunder-88xx.dtsi | 5 +
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/pmu.txt
> > b/Documentation/devicetree/bindings/arm/pmu.txt
> > index 5651883..d3999a1 100644
> > --- a/Documentation/devicetree/bindings/arm/pmu.txt
> > +++ b/Documentation/devicetree/bindings/arm/pmu.txt
> > @@ -25,6 +25,7 @@ Required properties:
> > "qcom,scorpion-pmu"
> > "qcom,scorpion-mp-pmu"
> > "qcom,krait-pmu"
> > + "cavium,thunder-pmu"
> > - interrupts : 1 combined interrupt or 1 per core. If the interrupt is a
> > per-cpu
> > interrupt (PPI) then 1 interrupt should be specified.
> >
> > diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> > b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> > index 9cb7cf9..2eb9b22 100644
> > --- a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> > +++ b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> > @@ -360,6 +360,11 @@
> > <1 10 0xff01>;
> > };
> >
> > + pmu {
> > + compatible = "cavium,thunder-pmu", "arm,armv8-pmuv3";
> > + interrupts = <1 7 4>;
> > + };
> > +
> > soc {
> > compatible = "simple-bus";
> > #address-cells = <2>;
> > --
> > 1.9.1
> >
Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80 characters
> But you are getting familiarized, you sent a patch, got feedback, defend > your patches.  That's a great start, but it does not mean that the > patches end up merged. The decision is up to the maintainer(s) of the > subsystem. > > Nobody will bite your head off if you do some trivial formal mistakes in > your first patch submissions. The mistakes will be pointed out, you will > be asked to resend.  Sometimes, when the mistakes or formalities are not > worth the email roundtrip, the maintainers fix it at commit time. So let's wait for a response from Chris. :)
Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80 characters
On Mon, Feb 22, 2016 at 06:10:56AM -0600, Simon Quigley wrote: > > in short, whitespace-only changes do not help too much. > > But they are encouraged for people who would like to get started with kernel > programming, Linus > himself says so. In the future I plan on giving more, but I wanted to get > familiarized with the > process. So I still think this should be accepted although it's just a > whitespace change. But you are getting familiarized, you sent a patch, got feedback, defend your patches. That's a great start, but it does not mean that the patches end up merged. The decision is up to the maintainer(s) of the subsystem. Nobody will bite your head off if you do some trivial formal mistakes in your first patch submissions. The mistakes will be pointed out, you will be asked to resend. Sometimes, when the mistakes or formalities are not worth the email roundtrip, the maintainers fix it at commit time.
Re: [PATCH 0/6] ARM: decompressor: several cleanups
Hi Russell, 2016-02-22 21:18 GMT+09:00 Russell King - ARM Linux : > On Mon, Feb 22, 2016 at 09:08:05PM +0900, Masahiro Yamada wrote: >> I did build-test, changing the configuration >> CONFIG_KERNEL_GZIP -> CONFIG_KERNEL_LZMA -> CONFIG_KERNEL_XZ -> ... >> >> I confirmed zImage was created from the expected piggy. >> >> For run-test, it worked fine too. > > Okay, please drop them into the patch system, thanks. I did so. Thanks. -- Best Regards Masahiro Yamada
Re: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
> Regression and a fix is required on top of this series. So can I send a > separate fix on top of this series ? Yes, do it like this. And please quote only relevant parts of a mail. signature.asc Description: PGP signature
Re: [PATCH] trace/irq: fix WARNING in check_flags while CONFIG_TRACE_IRQFLAGS opened
On Mon, Feb 22, 2016 at 06:06:45PM +0800, Wang Yufen wrote: > if CONFIG_TRACE_IRQFLAGS opened, we got that warning: > [ 214.078880] [ cut here ] > > [ 214.083521] WARNING: CPU: 4 PID: 1 at kernel/locking/lockdep.c:3557 > check_flags.part.40+0x1c0/0x1d0() I'm not entirely sure how to open a CONFIG_ symbol, but when I have it enabled, I do not get this warning. So your report is missing some critical information.
Re: [PATCH 1/2] cpufreq: governor: Fix race in dbs_update_util_handler()
On Mon, Feb 22, 2016 at 6:23 AM, Viresh Kumar wrote:
> On 21-02-16, 03:14, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki
>>
>> There is a scenarion that may lead to undesired results in
>
> scenario
>
>> dbs_update_util_handler(). Namely, if two CPUs sharing a policy
>> enter the funtion at the same time, pass the sample delay check
>> and then one of them is stalled until dbs_work_handler() (queued
>> up by the other CPU) clears the work counter, it may update the
>> work counter and queue up another work item prematurely.
>>
>> To prevent that from happening, use the observation that the CPU
>> queuing up a work item in dbs_update_util_handler() updates the
>> last sample time. This means that if another CPU was stalling after
>> passing the sample delay check and now successfully updated the work
>> counter as a result of the race described above, it will see the new
>> value of the last sample time which is different from what it used in
>> the sample delay check before. If that happens, the sample delay
>> check passed previously is not valid any more, so the CPU should not
>> continue, but leaving the funtion at that point might miss an
>> opportunity to take the next sample, so simply clear the work
>> counter and jump to the beginning of the function in that case.
>>
>> Fixes: f17cbb53783c (cpufreq: governor: Avoid atomic operations in hot paths)
>> Signed-off-by: Rafael J. Wysocki
>> ---
>> drivers/cpufreq/cpufreq_governor.c | 22 +-
>> 1 file changed, 17 insertions(+), 5 deletions(-)
>>
>> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
>> ===
>> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
>> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
>> @@ -341,8 +341,9 @@ static void dbs_update_util_handler(stru
>> {
>> struct cpu_dbs_info *cdbs = container_of(data, struct cpu_dbs_info,
>> update_util);
>> struct policy_dbs_info *policy_dbs = cdbs->policy_dbs;
>> - u64 delta_ns;
>> + u64 delta_ns, lst;
>>
>> + start:
>> /*
>>* The work may not be allowed to be queued up right now.
>>* Possible reasons:
>> @@ -357,7 +358,8 @@ static void dbs_update_util_handler(stru
>>* of sample_delay_ns used in the computation may be stale.
>>*/
>> smp_rmb();
>> - delta_ns = time - policy_dbs->last_sample_time;
>> + lst = ACCESS_ONCE(policy_dbs->last_sample_time);
>
> The comment on the top of ACCESS_ONCE() asks us to use READ_ONCE() if
> possible.
I forgot about this one, thanks!
>> + delta_ns = time - lst;
>> if ((s64)delta_ns < policy_dbs->sample_delay_ns)
>> return;
>>
>> @@ -366,9 +368,19 @@ static void dbs_update_util_handler(stru
>>* at this point. Otherwise, we need to ensure that only one of the
>>* CPUs sharing the policy will do that.
>>*/
>> - if (policy_dbs->is_shared &&
>> - !atomic_add_unless(&policy_dbs->work_count, 1, 1))
>> - return;
>> + if (policy_dbs->is_shared) {
>> + if (!atomic_add_unless(&policy_dbs->work_count, 1, 1))
>> + return;
>> +
>> + /*
>> + * If another CPU updated last_sample_time in the meantime, we
>> + * shouldn't be here, so clear the work counter and try again.
>> + */
>> + if (unlikely(lst !=
>> ACCESS_ONCE(policy_dbs->last_sample_time))) {
>> + atomic_set(&policy_dbs->work_count, 0);
>> + goto start;
>> + }
>
> I think we should be doing this here:
>
> delta_ns = time - ACCESS_ONCE(policy_dbs->last_sample_time);
> if ((s64)delta_ns < policy_dbs->sample_delay_ns) {
> atomic_set(&policy_dbs->work_count, 0);
> return;
> }
>
> There is no point running the routine again, we already have ->work_count
> incremented for us, lets do the check right now.
No, we need to check work_in_progress too.
> Over that, in theory, with your code, it is possible that one of the CPU can
> get
> stuck in the goto->start loop indefinitely :)
Good point (although that's not very likely to happen in practice).
There's one more problem, however. The value of time is already stale
at this point, so going to start and keeping the time value unmodified
is a mistake.
Let me respin the patch.
Thanks,
Rafael
RE: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
Hi Wolfram, > -Original Message- > From: Sricharan [mailto:sricha...@codeaurora.org] > Sent: Saturday, February 13, 2016 12:29 PM > To: 'Wolfram Sang' > Cc: 'devicet...@vger.kernel.org'; 'linux-arm-...@vger.kernel.org'; > 'agr...@codeaurora.org'; 'linux-kernel@vger.kernel.org'; 'linux- > i...@vger.kernel.org'; 'iiva...@mm-sol.com'; 'ga...@codeaurora.org'; > 'dmaeng...@vger.kernel.org'; 'linux-arm-ker...@lists.infradead.org'; > 'andy.gr...@linaro.org'; 'ntel...@codeaurora.org'; 'arch...@codeaurora.org' > Subject: RE: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities > > Hi Wolfram, > > > -Original Message- > > From: Wolfram Sang [mailto:w...@the-dreams.de] > > Sent: Saturday, February 13, 2016 12:08 AM > > To: Sricharan R > > Cc: devicet...@vger.kernel.org; linux-arm-...@vger.kernel.org; > > agr...@codeaurora.org; linux-kernel@vger.kernel.org; linux- > > i...@vger.kernel.org; iiva...@mm-sol.com; ga...@codeaurora.org; > > dmaeng...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > > andy.gr...@linaro.org; ntel...@codeaurora.org; arch...@codeaurora.org > > Subject: Re: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities > > > > On Tue, Jan 19, 2016 at 03:32:44PM +0530, Sricharan R wrote: > > > QUP cores can be attached to a BAM module, which acts as a dma > > > engine for the QUP core. When DMA with BAM is enabled, the BAM > > > consumer > > pipe > > > transmitted data is written to the output FIFO and the BAM producer > > > pipe received data is read from the input FIFO. > > > > > > With BAM capabilities, qup-i2c core can transfer more than > > > 256 bytes, without a 'stop' which is not possible otherwise. > > > > > > Signed-off-by: Sricharan R > > > Reviewed-by: Andy Gross > > > Tested-by: Archit Taneja > > > Tested-by: Telkar Nagender > > > > My code checkers found some issues: > > > > SPARSE > > drivers/i2c/busses/i2c-qup.c:555:6: warning: symbol 'qup_sg_set_buf' > > was not declared. Should it be static? > > drivers/i2c/busses/i2c-qup.c:1243:50: warning: dubious: !x & !y > > SMATCH > > drivers/i2c/busses/i2c-qup.c:165 qup_sg_set_buf warn: unused return: s > > = > > sg_next() > > drivers/i2c/busses/i2c-qup.c:165 qup_sg_set_buf warn: unused return: s > > = > > sg_next() > > drivers/i2c/busses/i2c-qup.c:1243 qup_i2c_xfer_v2() warn: add some > > parenthesis here? > > CPPCHECK > > drivers/i2c/busses/i2c-qup.c:1243: style: Boolean result is used in > > bitwise operation. Clarify expression with parentheses. > > SPATCH > > drivers/i2c/busses/i2c-qup.c:1380:2-13: WARNING: Assignment of bool to > > 0/1 > > drivers/i2c/busses/i2c-qup.c:1481:1-13: WARNING: Assignment of bool to > 0/1 > > CC drivers/i2c/busses/i2c-qup.o > > drivers/i2c/busses/i2c-qup.c:555:6: warning: no previous prototype for > > 'qup_sg_set_buf' [-Wmissing-prototypes] void qup_sg_set_buf(struct > > scatterlist *sg, void *buf, struct qup_i2c_tag *tg, > > > > Can you fix them and resend?? > Really sorry for the delay , sent it here [1] Also, while testing this series in one of a new platform, found that an additional Regression and a fix is required on top of this series. So can I send a separate fix on top of this series ? [1] https://patchwork.ozlabs.org/patch/586125/ Regards, Sricharan
Re: [PATCH 2/2] KVM: x86: MMU: Move handle_mmio_page_fault() call to kvm_mmu_page_fault()
On 22/02/2016 09:23, Takuya Yoshikawa wrote:
> Rather than placing a handle_mmio_page_fault() call in each
> vcpu->arch.mmu.page_fault() handler, moving it up to
> kvm_mmu_page_fault() makes the code better:
>
> - avoids code duplication
> - for kvm_arch_async_page_ready(), which is the other caller of
>vcpu->arch.mmu.page_fault(), removes an extra error_code check
> - avoids returning both RET_MMIO_PF_* values and raw integer values
>from vcpu->arch.mmu.page_fault()
>
> Signed-off-by: Takuya Yoshikawa
> ---
> arch/x86/kvm/mmu.c | 39 ---
> arch/x86/kvm/paging_tmpl.h | 19 ++-
> 2 files changed, 22 insertions(+), 36 deletions(-)
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index a28b734..2ce3892 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -3370,13 +3370,6 @@ static int nonpaging_page_fault(struct kvm_vcpu *vcpu,
> gva_t gva,
>
> pgprintk("%s: gva %lx error %x\n", __func__, gva, error_code);
>
> - if (unlikely(error_code & PFERR_RSVD_MASK)) {
> - r = handle_mmio_page_fault(vcpu, gva, true);
> -
> - if (likely(r != RET_MMIO_PF_INVALID))
> - return r;
> - }
> -
> r = mmu_topup_memory_caches(vcpu);
> if (r)
> return r;
> @@ -3460,13 +3453,6 @@ static int tdp_page_fault(struct kvm_vcpu *vcpu, gva_t
> gpa, u32 error_code,
>
> MMU_WARN_ON(!VALID_PAGE(vcpu->arch.mmu.root_hpa));
>
> - if (unlikely(error_code & PFERR_RSVD_MASK)) {
> - r = handle_mmio_page_fault(vcpu, gpa, true);
> -
> - if (likely(r != RET_MMIO_PF_INVALID))
> - return r;
> - }
> -
> r = mmu_topup_memory_caches(vcpu);
> if (r)
> return r;
> @@ -4361,18 +4347,27 @@ int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t
> cr2, u32 error_code,
> enum emulation_result er;
> bool direct = vcpu->arch.mmu.direct_map || mmu_is_nested(vcpu);
>
> + if (unlikely(error_code & PFERR_RSVD_MASK)) {
> + r = handle_mmio_page_fault(vcpu, cr2, direct);
> + if (r == RET_MMIO_PF_EMULATE) {
> + emulation_type = 0;
> + goto emulate;
> + }
> + if (r == RET_MMIO_PF_RETRY)
> + return 1;
> + if (r < 0)
> + return r;
It's a bit weird how RET_MMIO_PF_RETRY is zero, but unifying all the
return values of page fault routines is best left for another day.
Applied to queue, thanks.
Paolo
> + }
> +
> r = vcpu->arch.mmu.page_fault(vcpu, cr2, error_code, false);
> if (r < 0)
> - goto out;
> -
> - if (!r) {
> - r = 1;
> - goto out;
> - }
> + return r;
> + if (!r)
> + return 1;
>
> if (mmio_info_in_cache(vcpu, cr2, direct))
> emulation_type = 0;
> -
> +emulate:
> er = x86_emulate_instruction(vcpu, cr2, emulation_type, insn, insn_len);
>
> switch (er) {
> @@ -4386,8 +4381,6 @@ int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t
> cr2, u32 error_code,
> default:
> BUG();
> }
> -out:
> - return r;
> }
> EXPORT_SYMBOL_GPL(kvm_mmu_page_fault);
>
> diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
> index 6c9fed9..05827ff 100644
> --- a/arch/x86/kvm/paging_tmpl.h
> +++ b/arch/x86/kvm/paging_tmpl.h
> @@ -702,24 +702,17 @@ static int FNAME(page_fault)(struct kvm_vcpu *vcpu,
> gva_t addr, u32 error_code,
>
> pgprintk("%s: addr %lx err %x\n", __func__, addr, error_code);
>
> - if (unlikely(error_code & PFERR_RSVD_MASK)) {
> - r = handle_mmio_page_fault(vcpu, addr, mmu_is_nested(vcpu));
> - if (likely(r != RET_MMIO_PF_INVALID))
> - return r;
> -
> - /*
> - * page fault with PFEC.RSVD = 1 is caused by shadow
> - * page fault, should not be used to walk guest page
> - * table.
> - */
> - error_code &= ~PFERR_RSVD_MASK;
> - };
> -
> r = mmu_topup_memory_caches(vcpu);
> if (r)
> return r;
>
> /*
> + * If PFEC.RSVD is set, this is a shadow page fault.
> + * The bit needs to be cleared before walking guest page tables.
> + */
> + error_code &= ~PFERR_RSVD_MASK;
> +
> + /*
>* Look up the guest pte for the faulting address.
>*/
> r = FNAME(walk_addr)(&walker, vcpu, addr, error_code);
>
[PATCH] drm/rockchip: vop: fix crtc size in plane check
If the geometry of a crtc is changing in an atomic update then we much
validate the plane size against the new state of the crtc and not the
current size, otherwise if the crtc size is increasing the plane will be
cropped at the previous size and will not fill the screen.
Signed-off-by: John Keeping
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fd37054..82d55bd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -549,6 +549,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
struct drm_crtc *crtc = state->crtc;
+ struct drm_crtc_state *crtc_state;
struct drm_framebuffer *fb = state->fb;
struct vop_win *vop_win = to_vop_win(plane);
struct vop_plane_state *vop_plane_state = to_vop_plane_state(state);
@@ -563,12 +564,13 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
int max_scale = win->phy->scl ? FRAC_16_16(8, 1) :
DRM_PLANE_HELPER_NO_SCALING;
- crtc = crtc ? crtc : plane->state->crtc;
- /*
-* Both crtc or plane->state->crtc can be null.
-*/
if (!crtc || !fb)
goto out_disable;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
src->x1 = state->src_x;
src->y1 = state->src_y;
src->x2 = state->src_x + state->src_w;
@@ -580,8 +582,8 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
clip.x1 = 0;
clip.y1 = 0;
- clip.x2 = crtc->mode.hdisplay;
- clip.y2 = crtc->mode.vdisplay;
+ clip.x2 = crtc_state->adjusted_mode.hdisplay;
+ clip.y2 = crtc_state->adjusted_mode.vdisplay;
ret = drm_plane_helper_check_update(plane, crtc, state->fb,
src, dest, &clip,
--
2.7.0.226.gfe986fe
[PATCH 2/2 v2] chrdev: allocate dynamic chardevs in all unused holes
This is a duct-tape-and-chewing-gum solution to the problem with the major numbers running out when allocating major numbers dynamically. To avoid collisions in the major space, we supply a bitmap with "holes" that exist in the lower range of major numbers [0-254] and pick numbers from there, beginning with the unused char device 8 and moving up through 26, 40, 60-63, 93-94, 102, 120-127, 159, 213-215, 222-223 and 234-254. It will also FAIL if we actually fill up all free major numbers. This seems to me like the reasonable thing to do since the other numbers are, after all, reserved. This also adds the macro BITS() to so we can define the static bitmap at compiletime in a reasonable way. If someone prefer that I just put opaque hex numbers in there, then tell me, that works too, it's just not elegant IMO. This also deletes the comment /* temporary */ which must be one of the biggest lies ever. This also updates the Documentation/devices.txt document to reflect that all these numbers are used for dynamic assignment. Reported-by: Ying Huang Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: Alan Cox Cc: Arnd Bergmann Signed-off-by: Linus Walleij --- ChangeLog v1->v2: - Follow-up on the previous RFC patch, this uses Torvald's suggested bitmap approach to allocate devices instead of a list of free numbers. - As a result of using find_first_zero_bit(), the major numbers are assigned from low to high instead from high to low. It's a bit scarier but I guess drivers using dynamic numbers should be all right with it, I'm more worried about userspaces expecting dynamic majors to be in the [234,254] range. Input welcome, maybe I'm just chicken. - This still needs to be applied on top of the previous fix to start warning about going below major 234. If you prefer to just get this patch and get rid of the problem then tell me. --- Documentation/devices.txt | 22 ++ fs/char_dev.c | 46 ++ include/linux/bitops.h| 1 + include/linux/fs.h| 2 -- 4 files changed, 49 insertions(+), 22 deletions(-) diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 4035eca87144..2a4242be2fcd 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -248,6 +248,8 @@ Your cooperation is appreciated. associated with block devices. The binding to the loop devices is handled by mount(8) or losetup(8). + 8 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS + 8 block SCSI disk devices (0-15) 0 = /dev/sda First SCSI disk whole disk 16 = /dev/sdb Second SCSI disk whole disk @@ -620,7 +622,7 @@ Your cooperation is appreciated. 2 = /dev/sbpcd2 Panasonic CD-ROM controller 0 unit 2 3 = /dev/sbpcd3 Panasonic CD-ROM controller 0 unit 3 - 26 char + 26 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 26 block Second Matsushita (Panasonic/SoundBlaster) CD-ROM 0 = /dev/sbpcd4 Panasonic CD-ROM controller 1 unit 0 @@ -863,7 +865,7 @@ Your cooperation is appreciated. ... 39 block - 40 char + 40 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 40 block @@ -1127,7 +1129,7 @@ Your cooperation is appreciated. NAMING CONFLICT -- PROPOSED REVISED NAME /dev/rpda0 etc - 60-63 charLOCAL/EXPERIMENTAL USE + 60-63 charRESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 60-63 block LOCAL/EXPERIMENTAL USE Allocated for local/experimental use. For devices not @@ -1641,7 +1643,7 @@ Your cooperation is appreciated. disks (see major number 3) except that the limit on partitions is 15. - 93 char + 93 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 93 block NAND Flash Translation Layer filesystem 0 = /dev/nftlaFirst NFTL layer @@ -1649,7 +1651,7 @@ Your cooperation is appreciated. ... 240 = /dev/nftlp16th NTFL layer - 94 char + 94 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 94 block IBM S/390 DASD block storage 0 = /dev/dasda First DASD device, major @@ -1742,7 +1744,7 @@ Your cooperation is appreciated. ... 15 = /dev/amiraid/ar?p15 15th partition -102 char +102 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 102 block Compressed block device 0 = /dev/cbd/aFirst compressed block device, whole device @@ -2027,7 +2029,7 @@ Your cooperation is appreciated. 1 = /dev/vnet12nd virtual network ... -120-127 char LOCAL/EXPERIMENTAL USE +120-127 char RESERVED FOR DYNAMIC ALLOCATION OF MAJOR NUMBERS 120-127 block LOCAL/EXPERIMENTAL USE
Re: [PATCH 0/6] ARM: decompressor: several cleanups
On Mon, Feb 22, 2016 at 09:08:05PM +0900, Masahiro Yamada wrote: > I did build-test, changing the configuration > CONFIG_KERNEL_GZIP -> CONFIG_KERNEL_LZMA -> CONFIG_KERNEL_XZ -> ... > > I confirmed zImage was created from the expected piggy. > > For run-test, it worked fine too. Okay, please drop them into the patch system, thanks. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[RFD] Sharing GPIOs for input (buttons) and output (LEDs)
TL;DR: If a GPIO is connected to both a push button and an LED, can we
(1) still use both, or can we (2) chose which one to use?
This affects both the hardware description in DT and user policies.
Introduction
On the Renesas Salvator-X development board, 3 GPIO pins are connected to both
push buttons and LEDs.
- If the GPIO is configured for output, it can control the LED,
- If the GPIO is configured for input, the push button status can be
read. Note that the LED is on if the push button is not pressed; it is
turned off while holding the button.
DT Hardware Description
---
There exist device tree bindings for push buttons connected to GPIOs,
and the following works:
keyboard {
compatible = "gpio-keys";
key-a {
gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
label = "SW20";
wakeup-source;
linux,code = ;
};
key-b {
gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
label = "SW21";
wakeup-source;
linux,code = ;
};
key-c {
gpios = <&gpio6 13 GPIO_ACTIVE_LOW>;
label = "SW22";
wakeup-source;
linux,code = ;
};
};
There exist device tree bindings for LEDs connected to GPIOs, and the
following also works:
leds {
compatible = "gpio-leds";
led4 {
gpios = <&gpio6 11 GPIO_ACTIVE_HIGH>;
label = "LED4";
};
led5 {
gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
label = "LED5";
};
led6 {
gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
label = "LED6";
};
};
However, having both in the DTS doesn't mean you'll have working buttons
and LEDs. The first driver initialized will bind to the GPIOs. The
second driver will fail to initialize as the GPIOs are already busy.
One option to solve this is to introduce new bindings for GPIOs shared
by push buttons and LEDs. But that isn't without its own set of
problems. E.g. in my case the buttons use GPIO_ACTIVE_LOW, while the
LEDs use GPIO_ACTIVE_HIGH (I'm sure other combinations are possible),
which is supposed to be encoded in the GPIO descriptor.
Hence I'm inclined to keep the existing bindings, as they do describe
the hardware.
Device Driver
-
As a proof-of-concept, I hacked up a new driver that binds to both
"gpio-keys" and "gpio-leds", by combining the existing gpio-keys-polled
and gpio-leds drivers.
If a GPIO is found busy during initialization, and if it's already in
use by the other half of the driver, the driver switches to a special
"polled-key-and-LED" mode. I.e. during polling, it does:
- Save the GPIO output state,
- Switch the GPIO to input mode,
- Wait 5 ms (else it will read the old output state, depending on
e.g. hardware capacitance),
- Read the GPIO input state,
- Switch the GPIO to output mode,
- Restore the GPIO output state.
And it works, the LEDs can be controlled, and the push button states can
be read!
However, due to the 5 ms delay, there's a visible flickering of LEDs
that are supposed to be turned off (remember, when the GPIO is
configured for input and the button is not pressed, the LED is lit).
If we go this route, adding support for non-polled GPIOs (if the GPIO is
not shared with an LED) and wake-up should be doable.
User Policies
-
Hence we can have support for GPIOs connected to both push buttons and
LEDs. But perhaps the user doesn't want to use both at the same time,
or not for all GPIOs. On a final product this is probably not the case,
but it is on a development board like Salvator-X.
If it wasn't for the visible flickering when both are enabled, this
wouldn't matter. But the flickering may be considered annoying, so it
would be good if the user could disable either the push button or LED by
software.
One option is to disable the keyboard node using a DT overlay. But
that's cheating, as it modifies the hardware description, while this is
clearly a user policy.
Another use case would be to use the LEDs, and not the buttons, except
for system wake-up. Then there wouldn't be a need to poll during normal
system operation.
Thanks for your comments!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 3/3] vfs: Use per-cpu list for superblock's inode list
On Mon, Feb 22, 2016 at 12:54:35PM +0100, Jan Kara wrote: > > Also, I think fsnotify_unmount_inodes() (as per mainline) is missing a > > final iput(need_iput) at the very end, but I could be mistaken, that > > code hurts my brain. > > I think the code is actually correct since need_iput contains "inode > further in the list than the current inode". Thus we will always go though > another iteration of the loop which will drop the reference. And inode > cannot change state to I_FREEING or I_WILL_FREE because we hold inode > reference. But it is subtle as hell so I agree that code needs rewrite. So while talking to dchinner, he doubted fsnotify will actually remove inodes from the sb-list, but wasn't sure and too tired to check now. (I got lost in the fsnotify code real quick and gave up, for I was mostly trying to make a point that we don't need the CPP magic and can do with 'readable' code). If it doesn't, it doesn't need to do this extra special magic dance and can use the 'normal' iterator pattern used in all the other functions, greatly reducing complexity.
Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80 characters
> in short, whitespace-only changes do not help too much. But they are encouraged for people who would like to get started with kernel programming, Linus himself says so. In the future I plan on giving more, but I wanted to get familiarized with the process. So I still think this should be accepted although it's just a whitespace change. signature.asc Description: This is a digitally signed message part
Re: [patch V2 26/28] x86/perf/intel/rapl: Convert it to a per package facility
On Mon, Feb 22, 2016 at 11:07:02AM -, Thomas Gleixner wrote:
> +static inline struct rapl_pmu *cpu_to_rapl_pmu(unsigned int cpu)
> +{
> + return rapl_pmus->pmus[topology_logical_package_id(cpu)];
> +}
> @@ -370,6 +378,7 @@ static int rapl_pmu_event_init(struct pe
> return -EINVAL;
>
> /* must be done before validate_group */
> + pmu = cpu_to_rapl_pmu(event->cpu);
> event->cpu = pmu->cpu;
> event->pmu_private = pmu;
This again looks like pmu_private is 'trivially' replacable with
something like:
static inline struct rapl_pmu *event_to_rapl_pmu(struct perf_event *event)
{
return cpu_to_rapl_pmu(event->cpu);
}
Re: [patch V2 27/28] perf: Export perf_event_sysfs_show
On Mon, Feb 22, 2016 at 11:07:03AM -, Thomas Gleixner wrote: > Required to use it in modular perf drivers. > > Signed-off-by: Thomas Gleixner > --- > kernel/events/core.c |1 + > 1 file changed, 1 insertion(+) > > --- a/kernel/events/core.c > +++ b/kernel/events/core.c > @@ -9335,6 +9335,7 @@ ssize_t perf_event_sysfs_show(struct dev > > return 0; > } > +EXPORT_SYMBOL(perf_event_sysfs_show); perf exports are _GPL.
[RESEND PATCH V7 4/6] i2c: qup: Add bam dma capabilities
QUP cores can be attached to a BAM module, which acts as
a dma engine for the QUP core. When DMA with BAM is enabled,
the BAM consumer pipe transmitted data is written to the
output FIFO and the BAM producer pipe received data is read
from the input FIFO.
With BAM capabilities, qup-i2c core can transfer more than
256 bytes, without a 'stop' which is not possible otherwise.
Signed-off-by: Sricharan R
Reviewed-by: Andy Gross
Tested-by: Archit Taneja
Tested-by: Telkar Nagender
---
Fixed Sparse/Static warnings.
drivers/i2c/busses/i2c-qup.c | 473 +--
1 file changed, 459 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index f9009d6..30f3a2b 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -14,8 +14,12 @@
*
*/
+#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -24,6 +28,7 @@
#include
#include
#include
+#include
/* QUP Registers */
#define QUP_CONFIG 0x000
@@ -33,6 +38,7 @@
#define QUP_OPERATIONAL0x018
#define QUP_ERROR_FLAGS0x01c
#define QUP_ERROR_FLAGS_EN 0x020
+#define QUP_OPERATIONAL_MASK 0x028
#define QUP_HW_VERSION 0x030
#define QUP_MX_OUTPUT_CNT 0x100
#define QUP_OUT_FIFO_BASE 0x110
@@ -52,6 +58,7 @@
#define QUP_STATE_VALIDBIT(2)
#define QUP_I2C_MAST_GEN BIT(4)
+#define QUP_I2C_FLUSH BIT(6)
#define QUP_OPERATIONAL_RESET 0x000ff0
#define QUP_I2C_STATUS_RESET 0xfc
@@ -77,7 +84,10 @@
/* Packing/Unpacking words in FIFOs, and IO modes */
#define QUP_OUTPUT_BLK_MODE(1 << 10)
+#define QUP_OUTPUT_BAM_MODE(3 << 10)
#define QUP_INPUT_BLK_MODE (1 << 12)
+#define QUP_INPUT_BAM_MODE (3 << 12)
+#define QUP_BAM_MODE (QUP_OUTPUT_BAM_MODE | QUP_INPUT_BAM_MODE)
#define QUP_UNPACK_EN BIT(14)
#define QUP_PACK_ENBIT(15)
@@ -94,6 +104,8 @@
#define QUP_TAG_DATA (2 << 8)
#define QUP_TAG_STOP (3 << 8)
#define QUP_TAG_REC(4 << 8)
+#define QUP_BAM_INPUT_EOT 0x93
+#define QUP_BAM_FLUSH_STOP 0x96
/* QUP v2 tags */
#define QUP_TAG_V2_START 0x81
@@ -114,6 +126,12 @@
#define ONE_BYTE 0x1
#define QUP_I2C_MX_CONFIG_DURING_RUN BIT(31)
+#define MX_TX_RX_LEN SZ_64K
+#define MX_BLOCKS (MX_TX_RX_LEN / QUP_READ_LIMIT)
+
+/* Max timeout in ms for 32k bytes */
+#define TOUT_MAX 300
+
struct qup_i2c_block {
int count;
int pos;
@@ -123,6 +141,17 @@ struct qup_i2c_block {
u8 tags[6];
};
+struct qup_i2c_tag {
+ u8 *start;
+ dma_addr_t addr;
+};
+
+struct qup_i2c_bam {
+ struct qup_i2c_tag tag;
+ struct dma_chan *dma;
+ struct scatterlist *sg;
+};
+
struct qup_i2c_dev {
struct device *dev;
void __iomem*base;
@@ -154,6 +183,13 @@ struct qup_i2c_dev {
/* To configure when bus is in run state */
int config_run;
+ /* dma parameters */
+ boolis_dma;
+ struct dma_pool *dpool;
+ struct qup_i2c_tag start_tag;
+ struct qup_i2c_bam brx;
+ struct qup_i2c_bam btx;
+
struct completion xfer;
};
@@ -230,6 +266,14 @@ static int qup_i2c_poll_state(struct qup_i2c_dev *qup, u32
req_state)
return qup_i2c_poll_state_mask(qup, req_state, QUP_STATE_MASK);
}
+static void qup_i2c_flush(struct qup_i2c_dev *qup)
+{
+ u32 val = readl(qup->base + QUP_STATE);
+
+ val |= QUP_I2C_FLUSH;
+ writel(val, qup->base + QUP_STATE);
+}
+
static int qup_i2c_poll_state_valid(struct qup_i2c_dev *qup)
{
return qup_i2c_poll_state_mask(qup, 0, 0);
@@ -437,12 +481,14 @@ static int qup_i2c_get_data_len(struct qup_i2c_dev *qup)
}
static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev *qup,
- struct i2c_msg *msg)
+ struct i2c_msg *msg, int is_dma)
{
u16 addr = (msg->addr << 1) | ((msg->flags & I2C_M_RD) == I2C_M_RD);
int len = 0;
int data_len;
+ int last = (qup->blk.pos == (qup->blk.count - 1)) && (qup->is_last);
+
if (qup->blk.pos == 0) {
tags[len++] = QUP_TAG_V2_START;
tags[len++] = addr & 0xff;
@@ -452,7 +498,7 @@ static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev
*qup,
}
/* Send _STOP commands for the last block */
- if ((qup->blk.pos == (qup->blk.count - 1)) && qup->is_last) {
+ if (last) {
if (msg->flags & I2C_M_RD)
tags[len++] = QUP_TAG_V2_DATARD_STOP;
else
@@ -472,6 +518,11 @@ static int qup_i2c_set_tags(u8 *ta
Re: [PATCH 0/6] ARM: decompressor: several cleanups
Hi Russell, 2016-02-22 20:36 GMT+09:00 Russell King - ARM Linux : > On Mon, Feb 22, 2016 at 04:31:11PM +0900, Masahiro Yamada wrote: >> Masahiro Yamada (6): >> ARM: decompressor: drop unneeded assignments to "targets" >> ARM: decompressor: drop more unneeded assignments to "targets" >> ARM: decompressor: use clean-files instead of extra-y to clean files >> ARM: decompressor: drop redundant FORCE in Makefile >> ARM: decompressor: merge piggy.*.S and simplify Makefile >> ARM: decompressor: rename suffix_y to compress-y > > Most of this looks fine to me, but I've a question about how thoroughly > patch 5 has been tested: iow, do we get correct behaviour if only the > compression method is changed? > > Thanks. I did build-test, changing the configuration CONFIG_KERNEL_GZIP -> CONFIG_KERNEL_LZMA -> CONFIG_KERNEL_XZ -> ... I confirmed zImage was created from the expected piggy. For run-test, it worked fine too. -- Best Regards Masahiro Yamada
[v2 PATCH 3/3] scsi:stex.c Add S3/S4 support
From: Charles
Add S3/S4 support, add .suspend and .resume function in pci_driver.
In .suspend handler, driver send S3/S4 signal to the device.
Signed-off-by: Charles Chiou
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/stex.c | 68 ++---
1 file changed, 65 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 1994603..5b23175 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -167,6 +167,14 @@ enum {
ST_ADDITIONAL_MEM = 0x20,
ST_ADDITIONAL_MEM_MIN = 0x8,
+ PMIC_SHUTDOWN = 0x0D,
+ PMIC_REUMSE = 0x10,
+ ST_IGNORED = -1,
+ ST_NOTHANDLED = 7,
+ ST_S3 = 3,
+ ST_S4 = 4,
+ ST_S5 = 5,
+ ST_S6 = 6,
};
struct st_sgitem {
@@ -1718,7 +1726,7 @@ out_disable:
return err;
}
-static void stex_hba_stop(struct st_hba *hba)
+static void stex_hba_stop(struct st_hba *hba, int st_sleep_mic)
{
struct req_msg *req;
struct st_msg_header *msg_h;
@@ -1727,6 +1735,15 @@ static void stex_hba_stop(struct st_hba *hba)
u16 tag = 0;
spin_lock_irqsave(hba->host->host_lock, flags);
+
+ if (hba->cardtype == st_yel && hba->supports_pm == 1)
+ {
+ if(st_sleep_mic == ST_NOTHANDLED)
+ {
+ spin_unlock_irqrestore(hba->host->host_lock, flags);
+ return;
+ }
+ }
req = hba->alloc_rq(hba);
if (hba->cardtype == st_yel) {
msg_h = (struct st_msg_header *)req - 1;
@@ -1734,11 +1751,18 @@ static void stex_hba_stop(struct st_hba *hba)
} else
memset(req, 0, hba->rq_size);
- if (hba->cardtype == st_yosemite || hba->cardtype == st_yel) {
+ if ((hba->cardtype == st_yosemite || hba->cardtype == st_yel)
+ && st_sleep_mic == ST_IGNORED) {
req->cdb[0] = MGT_CMD;
req->cdb[1] = MGT_CMD_SIGNATURE;
req->cdb[2] = CTLR_CONFIG_CMD;
req->cdb[3] = CTLR_SHUTDOWN;
+ } else if (hba->cardtype == st_yel && st_sleep_mic != ST_IGNORED) {
+ req->cdb[0] = MGT_CMD;
+ req->cdb[1] = MGT_CMD_SIGNATURE;
+ req->cdb[2] = CTLR_CONFIG_CMD;
+ req->cdb[3] = PMIC_SHUTDOWN;
+ req->cdb[4] = st_sleep_mic;
} else {
req->cdb[0] = CONTROLLER_CMD;
req->cdb[1] = CTLR_POWER_STATE_CHANGE;
@@ -1758,10 +1782,12 @@ static void stex_hba_stop(struct st_hba *hba)
while (hba->ccb[tag].req_type & PASSTHRU_REQ_TYPE) {
if (time_after(jiffies, before + ST_INTERNAL_TIMEOUT * HZ)) {
hba->ccb[tag].req_type = 0;
+ hba->mu_status = MU_STATE_STOP;
return;
}
msleep(1);
}
+ hba->mu_status = MU_STATE_STOP;
}
static void stex_hba_free(struct st_hba *hba)
@@ -1801,9 +1827,43 @@ static void stex_shutdown(struct pci_dev *pdev)
{
struct st_hba *hba = pci_get_drvdata(pdev);
- stex_hba_stop(hba);
+ if (hba->supports_pm == 0)
+ stex_hba_stop(hba, ST_IGNORED);
+ else
+ stex_hba_stop(hba, ST_S5);
+}
+
+static int stex_choice_sleep_mic(pm_message_t state)
+{
+ switch (state.event) {
+ case PM_EVENT_SUSPEND:
+ return ST_S3;
+ case PM_EVENT_HIBERNATE:
+ return ST_S4;
+ default:
+ return ST_NOTHANDLED;
+ }
}
+static int stex_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ struct st_hba *hba = pci_get_drvdata(pdev);
+
+ if (hba->cardtype == st_yel && hba->supports_pm == 1)
+ stex_hba_stop(hba, stex_choice_sleep_mic(state));
+ else
+ stex_hba_stop(hba, ST_IGNORED);
+ return 0;
+}
+
+static int stex_resume(struct pci_dev *pdev)
+{
+ struct st_hba *hba = pci_get_drvdata(pdev);
+
+ hba->mu_status = MU_STATE_STARTING;
+ stex_handshake(hba);
+ return 0;
+}
MODULE_DEVICE_TABLE(pci, stex_pci_tbl);
static struct pci_driver stex_pci_driver = {
@@ -1812,6 +1872,8 @@ static struct pci_driver stex_pci_driver = {
.probe = stex_probe,
.remove = stex_remove,
.shutdown = stex_shutdown,
+ .suspend= stex_suspend,
+ .resume = stex_resume,
};
static int __init stex_init(void)
--
1.9.1
[v2 PATCH 2/3] scsi:stex.c Add hotplug support
From: Charles
1. Add hotplug support. Pegasus support surprise removal. To this end, I
use return_abnormal_state function to return DID_NO_CONNECT for all
commands which sent to driver.
2. Remove stex_hba_stop in stex_remove because we cannot send command to
device after hotplug.
3. Add new device status: MU_STATE_STOP, MU_STATE_NOCONNECT,
MU_STATE_STOP. MU_STATE_STOP is currently not referenced.
MU_STATE_NOCONNECT represent that device is plugged out from the host.
4. Use return_abnormal_function() to substitute part of code in stex_do_reset.
Signed-off-by: Charles Chiou
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/stex.c | 53 ++---
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 495d632..1994603 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -84,6 +84,8 @@ enum {
MU_STATE_STARTED= 2,
MU_STATE_RESETTING = 3,
MU_STATE_FAILED = 4,
+ MU_STATE_STOP = 5,
+ MU_STATE_NOCONNECT = 6,
MU_MAX_DELAY= 120,
MU_HANDSHAKE_SIGNATURE = 0x5555,
@@ -537,6 +539,27 @@ stex_ss_send_cmd(struct st_hba *hba, struct req_msg *req,
u16 tag)
readl(hba->mmio_base + YH2I_REQ); /* flush */
}
+static void return_abnormal_state(struct st_hba *hba, int status)
+{
+ struct st_ccb *ccb;
+ unsigned long flags;
+ u16 tag;
+
+ spin_lock_irqsave(hba->host->host_lock, flags);
+ for (tag = 0; tag < hba->host->can_queue; tag++) {
+ ccb = &hba->ccb[tag];
+ if (ccb->req == NULL)
+ continue;
+ ccb->req = NULL;
+ if (ccb->cmd) {
+ scsi_dma_unmap(ccb->cmd);
+ ccb->cmd->result = status << 16;
+ ccb->cmd->scsi_done(ccb->cmd);
+ ccb->cmd = NULL;
+ }
+ }
+ spin_unlock_irqrestore(hba->host->host_lock, flags);
+}
static int
stex_slave_config(struct scsi_device *sdev)
{
@@ -560,8 +583,12 @@ stex_queuecommand_lck(struct scsi_cmnd *cmd, void
(*done)(struct scsi_cmnd *))
id = cmd->device->id;
lun = cmd->device->lun;
hba = (struct st_hba *) &host->hostdata[0];
-
- if (unlikely(hba->mu_status == MU_STATE_RESETTING))
+ if (hba->mu_status == MU_STATE_NOCONNECT) {
+ cmd->result = DID_NO_CONNECT;
+ done(cmd);
+ return 0;
+ }
+ if (unlikely(hba->mu_status != MU_STATE_STARTED))
return SCSI_MLQUEUE_HOST_BUSY;
switch (cmd->cmnd[0]) {
@@ -1260,10 +1287,8 @@ static void stex_ss_reset(struct st_hba *hba)
static int stex_do_reset(struct st_hba *hba)
{
- struct st_ccb *ccb;
unsigned long flags;
unsigned int mu_status = MU_STATE_RESETTING;
- u16 tag;
spin_lock_irqsave(hba->host->host_lock, flags);
if (hba->mu_status == MU_STATE_STARTING) {
@@ -1297,20 +1322,8 @@ static int stex_do_reset(struct st_hba *hba)
else if (hba->cardtype == st_yel)
stex_ss_reset(hba);
- spin_lock_irqsave(hba->host->host_lock, flags);
- for (tag = 0; tag < hba->host->can_queue; tag++) {
- ccb = &hba->ccb[tag];
- if (ccb->req == NULL)
- continue;
- ccb->req = NULL;
- if (ccb->cmd) {
- scsi_dma_unmap(ccb->cmd);
- ccb->cmd->result = DID_RESET << 16;
- ccb->cmd->scsi_done(ccb->cmd);
- ccb->cmd = NULL;
- }
- }
- spin_unlock_irqrestore(hba->host->host_lock, flags);
+
+ return_abnormal_state(hba, DID_RESET);
if (stex_handshake(hba) == 0)
return 0;
@@ -1771,9 +1784,11 @@ static void stex_remove(struct pci_dev *pdev)
{
struct st_hba *hba = pci_get_drvdata(pdev);
+ hba->mu_status = MU_STATE_NOCONNECT;
+ return_abnormal_state(hba, DID_NO_CONNECT);
scsi_remove_host(hba->host);
- stex_hba_stop(hba);
+ scsi_block_requests(hba->host);
stex_hba_free(hba);
--
1.9.1
[PATCH] bus: imx-weim: Take the 'status' property value into account
From: Fabio Estevam
Currently we have an incorrect behaviour when multiple devices
are present under the weim node. For example:
&weim {
...
status = "okay";
sram@0,0 {
...
status = "okay";
};
mram@0,0 {
...
status = "disabled";
};
};
In this case only the 'sram' device should be probed and not 'mram'.
However what happens currently is that the status variable is ignored,
causing the 'sram' device to be disabled and 'mram' to be enabled.
Change the weim_parse_dt() function to use
for_each_available_child_of_node()so that the devices marked with
'status = disabled' are not probed.
Cc:
Suggested-by: Wolfgang Netbal
Signed-off-by: Fabio Estevam
---
drivers/bus/imx-weim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index e98d15e..1827fc4 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -150,7 +150,7 @@ static int __init weim_parse_dt(struct platform_device
*pdev,
return ret;
}
- for_each_child_of_node(pdev->dev.of_node, child) {
+ for_each_available_child_of_node(pdev->dev.of_node, child) {
if (!child->name)
continue;
--
1.9.1
Re: [patch V2 10/28] x86/perf/intel_uncore: Store box in event->pmu_private
On Mon, 22 Feb 2016, Peter Zijlstra wrote:
> On Mon, Feb 22, 2016 at 11:06:50AM -, Thomas Gleixner wrote:
> > + event->pmu_private = box;
>
> > +static inline struct intel_uncore_box *uncore_event_to_box(struct
> > perf_event *event)
> > +{
> > + return event->pmu_private;
> > +}
>
> Do you really need this? That is, what is wrong with:
>
> static inline struct intel_uncore_box *uncore_event_to_box(struct perf_event
> *event)
> {
> return uncore_pmu_to_box(event->pmu, event->cpu);
> }
>
> Which, after patch 12, should be fairly trivial, right?
Yes.
[v2 PATCH 1/3] scsi:stex.c Support to Pegasus series.
From: Charles
Pegasus is a high performace hardware RAID solution designed to unleash
the raw power of Thunderbolt technology.
1. Add code to distinct SuperTrack and Pegasus series by sub device ID.
It should support backward compatibility.
2. Change the driver version.
Signed-off-by: Charles Chiou
Reviewed-by: Johannes Thumshirn
---
drivers/scsi/stex.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/stex.c b/drivers/scsi/stex.c
index 2de28d7..495d632 100644
--- a/drivers/scsi/stex.c
+++ b/drivers/scsi/stex.c
@@ -1,7 +1,7 @@
/*
* SuperTrak EX Series Storage Controller driver for Linux
*
- * Copyright (C) 2005-2009 Promise Technology Inc.
+ * Copyright (C) 2005-2015 Promise Technology Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -38,11 +38,11 @@
#include
#define DRV_NAME "stex"
-#define ST_DRIVER_VERSION "4.6..4"
-#define ST_VER_MAJOR 4
-#define ST_VER_MINOR 6
-#define ST_OEM 0
-#define ST_BUILD_VER 4
+#define ST_DRIVER_VERSION "5.00..01"
+#define ST_VER_MAJOR 5
+#define ST_VER_MINOR 00
+#define ST_OEM
+#define ST_BUILD_VER 01
enum {
/* MU register offset */
@@ -328,6 +328,7 @@ struct st_hba {
u16 rq_count;
u16 rq_size;
u16 sts_count;
+ u8 supports_pm;
};
struct st_card_info {
@@ -1560,6 +1561,25 @@ static int stex_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
hba->cardtype = (unsigned int) id->driver_data;
ci = &stex_card_info[hba->cardtype];
+ switch (id->subdevice) {
+ case 0x4221:
+ case 0x4222:
+ case 0x4223:
+ case 0x4224:
+ case 0x4225:
+ case 0x4226:
+ case 0x4227:
+ case 0x4261:
+ case 0x4262:
+ case 0x4263:
+ case 0x4264:
+ case 0x4265:
+ break;
+ default:
+ if (hba->cardtype == st_yel)
+ hba->supports_pm = 1;
+ }
+
sts_offset = scratch_offset = (ci->rq_count+1) * ci->rq_size;
if (hba->cardtype == st_yel)
sts_offset += (ci->sts_count+1) * sizeof(u32);
--
1.9.1
Re: [patch V2 13/28] x86/perf/intel_uncore: Clear all hardware state on exit
On Mon, 22 Feb 2016, Peter Zijlstra wrote:
> On Mon, Feb 22, 2016 at 11:06:52AM -, Thomas Gleixner wrote:
> > +static void __init uncore_exit_boxes(void *dummy)
> > +{
> > + struct intel_uncore_type **types = uncore_msr_uncores;
> > +
> > + while (*types)
> > + __uncore_exit_boxes(*types++, smp_processor_id());
>
> for (types = uncore_msr_uncores; *types; types++)
> __uncore_exit_boxes(*types, smp_processor_id());
>
> > +}
>
> You flipped to for() loops in the other places, figures this one should
> match?
Yes. Forgot about that one.
Re: [patch V2 10/28] x86/perf/intel_uncore: Store box in event->pmu_private
On Mon, 22 Feb 2016, Peter Zijlstra wrote: > On Mon, Feb 22, 2016 at 11:06:50AM -, Thomas Gleixner wrote: > > Index: b/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c > > === > > --- a/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c > > +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c > > @@ -313,6 +313,7 @@ static int snb_uncore_imc_event_init(str > > return -EINVAL; > > > > event->cpu = box->cpu; > > + event->pmu_private = pmu; > > This seems rather pointless, did you want that to be '= box' instead? Duh, yes.
Re: [patch V2 13/28] x86/perf/intel_uncore: Clear all hardware state on exit
On Mon, Feb 22, 2016 at 11:06:52AM -, Thomas Gleixner wrote:
> +static void __init uncore_exit_boxes(void *dummy)
> +{
> + struct intel_uncore_type **types = uncore_msr_uncores;
> +
> + while (*types)
> + __uncore_exit_boxes(*types++, smp_processor_id());
for (types = uncore_msr_uncores; *types; types++)
__uncore_exit_boxes(*types, smp_processor_id());
> +}
You flipped to for() loops in the other places, figures this one should
match?
Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80 characters
On Sat, Feb 20, 2016 at 12:17:38PM -0600, Simon Quigley wrote: > checkpatch.pl reported a warning of over 80 characters on line 1833 Please read the answers from Filipe or me http://article.gmane.org/gmane.comp.file-systems.btrfs/53421 http://article.gmane.org/gmane.comp.file-systems.btrfs/53422 in short, whitespace-only changes do not help too much.
[PATCH v3] spi: master driver to enable RTC on ICPDAS LP-8841
ICP DAS LP-8841 contains a DS-1302 RTC. This driver provides an SPI
master which makes the RTC usable. The driver is not supposed to work
with anything else.
The driver uses the standard MicroWire half-duplex transfer timing.
Master output is set on low clock and sensed by the RTC on the rising
edge. Master input is set by the RTC on the trailing edge and is sensed
by the master on low clock.
Signed-off-by: Sergei Ianovich
CC: Mark Brown
---
v2..v3 to fix Mark Brown review comments
* drop dependencies in Kconfig
* use #ifdef CONFIG_OF to allow build without DT
* drop empty driver->remove
v1..v2 to fix Mark Brown review comments
* drop ifdef around MODULE_NAME
* use usleep_range directly
* drop empty master->cleanup
.../devicetree/bindings/spi/spi-lp8841-rtc.txt | 55 +
drivers/spi/Kconfig| 9 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-lp8841-rtc.c | 255 +
4 files changed, 320 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-lp8841-rtc.txt
create mode 100644 drivers/spi/spi-lp8841-rtc.c
diff --git a/Documentation/devicetree/bindings/spi/spi-lp8841-rtc.txt
b/Documentation/devicetree/bindings/spi/spi-lp8841-rtc.txt
new file mode 100644
index 000..f191aef
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-lp8841-rtc.txt
@@ -0,0 +1,55 @@
+* ICP DAS LP-8841 SPI Controller for RTC
+
+ICP DAS LP-8841 contains a DS-1302 RTC. This driver provides an SPI
+master which makes the RTC usable. The driver is not supposed to work
+with anything else.
+
+The driver uses the standard MicroWire half-duplex transfer timing.
+Master output is set on low clock and sensed by the RTC on the rising
+edge. Master input is set by the RTC on the trailing edge and is sensed
+by the master on low clock.
+
+Required properties:
+
+- #address-cells: should be 1
+
+- #size-cells: should be 0
+
+- compatible: should be "icpdas,spi-lp8841-rtc"
+
+- reg: should provide IO memory address
+
+Requirements to SPI slave nodes:
+
+- There can be only one slave device.
+
+- The spi slave node should claim the following flags which are
+ required by the spi controller.
+
+ - spi-3wire: The master itself has only 3 wire. It cannor work in
+full duplex mode.
+
+ - spi-cs-high: DS-1302 has active high chip select line. The master
+doesn't support active low.
+
+ - spi-lsb-first: DS-1302 requires least significant bit first
+transfers. The master only support this type of bit ordering.
+
+
+Example:
+
+spi0@901c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "icpdas,spi-lp8841-rtc";
+ reg = <0x901c 0x1>;
+
+ rtc@0 {
+ compatible = "maxim,rtc-ds1302";
+ reg = <0>;
+ spi-max-frequency = <50>;
+ spi-3wire;
+ spi-lsb-first;
+ spi-cs-high;
+ };
+};
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 7706416..6a6626a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -271,6 +271,15 @@ config SPI_LM70_LLP
which interfaces to an LM70 temperature sensor using
a parallel port.
+config SPI_LP8841_RTC
+ tristate "ICP DAS LP-8841 SPI Controller for RTC"
+ help
+ This driver provides an SPI master device to drive Maxim
+ DS-1302 real time clock.
+
+ Say N here unless you plan to run the kernel on an ICP DAS
+ LP-8x4x industrial computer.
+
config SPI_MPC52xx
tristate "Freescale MPC52xx SPI (non-PSC) controller support"
depends on PPC_MPC52xx
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 8991ffc..9d10ddc 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_GPIO)+= spi-gpio.o
obj-$(CONFIG_SPI_IMG_SPFI) += spi-img-spfi.o
obj-$(CONFIG_SPI_IMX) += spi-imx.o
obj-$(CONFIG_SPI_LM70_LLP) += spi-lm70llp.o
+obj-$(CONFIG_SPI_LP8841_RTC) += spi-lp8841-rtc.o
obj-$(CONFIG_SPI_MESON_SPIFC) += spi-meson-spifc.o
obj-$(CONFIG_SPI_MPC512x_PSC) += spi-mpc512x-psc.o
obj-$(CONFIG_SPI_MPC52xx_PSC) += spi-mpc52xx-psc.o
diff --git a/drivers/spi/spi-lp8841-rtc.c b/drivers/spi/spi-lp8841-rtc.c
new file mode 100644
index 000..ae177bc
--- /dev/null
+++ b/drivers/spi/spi-lp8841-rtc.c
@@ -0,0 +1,255 @@
+/*
+ * SPI master driver for ICP DAS LP-8841 RTC
+ *
+ * Copyright (C) 2016 Sergei Ianovich
+ *
+ * based on
+ *
+ * Dallas DS1302 RTC Support
+ * Copyright (C) 2002 David McCullough
+ * Copyright (C) 2003 - 2007 Paul Mundt
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+
[PATCH] MAINTAINERS: add qcom clocks to the maintainers list
This patch adds qcom clock drivers to the QCOM/MSM support list so that get_maintainer.pl can pick up correct cc list. Signed-off-by: Srinivas Kandagatla --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4978dc1..e76893a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1426,6 +1426,7 @@ F:arch/arm/boot/dts/qcom-*.dts F: arch/arm/boot/dts/qcom-*.dtsi F: arch/arm/mach-qcom/ F: arch/arm64/boot/dts/qcom/* +F: drivers/clk/qcom/ F: drivers/soc/qcom/ F: drivers/tty/serial/msm_serial.h F: drivers/tty/serial/msm_serial.c -- 1.9.1
[PATCH v5.2] phy: rockchip-usb: add handler for usb-uart functionality
Most newer Rockchip SoCs provide the possibility to use a usb-phy
as passthrough for the debug uart (uart2), making it possible to
for example get console output without needing to open the device.
This patch adds an early_initcall to enable this functionality
conditionally via the commandline and also disables the corresponding
usb controller in the devicetree.
Currently only data for the rk3288 is provided, but at least the
rk3188 and arm64 rk3368 also provide this functionality and will be
enabled later.
On a spliced usb cable the signals are tx on white wire(D+) and
rx on green wire(D-).
The one caveat is that currently the reconfiguration of the phy
happens as early_initcall, as the code depends on the unflattened
devicetree being available. Everything is fine if only a regular
console is active as the console-replay will happen after the
reconfiguation. But with earlycon active output up to smp-init
currently will get lost.
The phy is an optional property for the connected dwc2 controller,
so we still provide the phy device but fail all phy-ops with -EBUSY
to make sure the dwc2 does not try to transmit anything on the
repurposed phy.
Signed-off-by: Heiko Stuebner
---
changes in v5.2:
- pristine git send-email now to fix strange encoding effects
changes in v5.1:
- fix corruptions that happened when sending v5
changes in v5:
- only compile debug uart functionality if the phy is compiled in
fixes initcall conflict and debug functionality also is only really
usable if it's available early
changes in v4:
- drop the rest of the phy-series, as the patches have gotten applied
So far, this hasn't gotten eyeballs yet, so citing discussion-parts from
the v3 coverletter:
The patch, while not associated with the new pll handling, also builds
on the groundwork introduced there and adds support for the function
repurposing one of the phys as passthrough for uart-data. This enables
attaching a ttl converter to the D+ and D- pins of an usb cable to
receive uart data this way, when it is not really possible to attach
a regular serial console to a board.
One point of critique in my first iteration [0] of this was, that
due to when the reconfiguration happens we may miss parts of the logs
when earlycon is enabled. So far early_initcall gets used as the
unflattened devicetree is necessary to set this up. Doing this for
example in the early_param directly would require parsing the flattened
devicetree to get needed nodes and properties.
I still maintain that if you're working on anything before smp-bringup
you should use a real dev-board instead or try to solder uart cables
on hopefully available test-points .
Documentation/kernel-parameters.txt | 6 +
drivers/phy/phy-rockchip-usb.c | 233 ++--
2 files changed, 203 insertions(+), 36 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 87d40a7..d91417b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3486,6 +3486,12 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
ro [KNL] Mount root device read-only on boot
+ rockchip.usb_uart
+ Enable the uart passthrough on the designated usb port
+ on Rockchip SoCs. When active, the signals of the
+ debug-uart get routed to the D+ and D- pins of the usb
+ port and the regular usb controller gets disabled.
+
root= [KNL] Root filesystem
See name_to_dev_t comment in init/do_mounts.c.
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
index 33a80eb..f62d899 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -30,21 +30,23 @@
#include
#include
-/*
- * The higher 16-bit of this register is used for write protection
- * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
- */
-#define SIDDQ_WRITE_ENABIT(29)
-#define SIDDQ_ON BIT(13)
-#define SIDDQ_OFF (0 << 13)
+static int enable_usb_uart;
+
+#define HIWORD_UPDATE(val, mask) \
+ ((val) | (mask) << 16)
+
+#define UOC_CON0_SIDDQ BIT(13)
struct rockchip_usb_phys {
int reg;
const char *pll_name;
};
+struct rockchip_usb_phy_base;
struct rockchip_usb_phy_pdata {
struct rockchip_usb_phys *phys;
+ int (*init_usb_uart)(struct regmap *grf);
+ int usb_uart_phy;
};
struct rockchip_usb_phy_base {
@@ -61,13 +63,15 @@ struct rockchip_usb_phy {
struct clk *clk480m;
struct clk_hw clk480m_hw;
struct phy *phy;
+ booluart_enabled;
};
static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
bool siddq)
{
- return regmap_write(phy->base->reg_base, phy->reg_offset,
- SIDDQ
Re: [PATCH v2 3/3] vfs: Use per-cpu list for superblock's inode list
On Mon 22-02-16 10:18:44, Peter Zijlstra wrote:
> On Mon, Feb 22, 2016 at 08:34:19AM +1100, Dave Chinner wrote:
> > On Fri, Feb 19, 2016 at 04:10:45PM -0500, Waiman Long wrote:
> > > +/*
> > > + * Superblock's inode list iterator function and arguments macros
> > > + */
> > > +#define SB_INODES_ITER_FUNC(name, lock, struct_fields)
> > > \
> > > + struct name ## _arg { \
> > > + struct_fields; \
> > > + }; \
> > > + static int name ## _iter(struct pcpu_list_node *_node, \
> > > + struct pcpu_list_node **_pnext,\
> > > + spinlock_t *lock, void *_arg)
> > > +
> > > +#define SB_INODES_ITER_ARGS(name, i, a)
> > > \
> > > + struct inode *i = container_of(_node, struct inode, i_sb_list); \
> > > + struct name ## _arg *a = (struct name ## _arg *)_arg
> > > +
> > > +#define SB_INODES_ITER_ARGS_SAFE(name, i, n, a)
> > > \
> > > + struct inode *i = container_of(_node, struct inode, i_sb_list); \
> > > + struct inode *n = container_of(*_pnext, struct inode, i_sb_list);\
> > > + struct name ## _arg *a = (struct name ## _arg *)_arg
> > > +
> > > +#define SB_INODES_ITER_SET_PCPU_LIST_NEXT(n)
> > > \
> > > + { *_pnext = &(n)->i_sb_list; }
> > > +
> > > +#define SB_INODES_ITER_CALL(name, sb)
> > > \
> > > + pcpu_list_iterate(sb->s_inodes, false, NULL, name ## _iter, &arg)
> > > +
> > > +#define SB_INODES_ITER_CALL_SAFE(name, sb, phead)
> > > \
> > > + pcpu_list_iterate(sb->s_inodes, true, phead, name ## _iter, &arg)
> > > +
> >
> > No, just no.
>
> Ha! See I was thinking of something more along the lines of the below.
>
> Which is completely untested and incomplete, but does illustrate the
> point.
>
> Also, I think fsnotify_unmount_inodes() (as per mainline) is missing a
> final iput(need_iput) at the very end, but I could be mistaken, that
> code hurts my brain.
I think the code is actually correct since need_iput contains "inode
further in the list than the current inode". Thus we will always go though
another iteration of the loop which will drop the reference. And inode
cannot change state to I_FREEING or I_WILL_FREE because we hold inode
reference. But it is subtle as hell so I agree that code needs rewrite.
Honza
>
> ---
> fs/block_dev.c | 51 +++---
> fs/drop_caches.c | 32 +---
> fs/fs-writeback.c | 65 --
> fs/notify/inode_mark.c | 93
> ++---
> fs/quota/dquot.c | 63 -
> fs/super.c | 65 +-
> include/linux/fs.h |9 ++--
> 7 files changed, 154 insertions(+), 224 deletions(-)
>
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -1862,38 +1862,29 @@ int __invalidate_device(struct block_dev
> }
> EXPORT_SYMBOL(__invalidate_device);
>
> -void iterate_bdevs(void (*func)(struct block_device *, void *), void *arg)
> -{
> - struct inode *inode, *old_inode = NULL;
> +struct iterate_bdevs_data {
> + void (*func)(struct block_device *, void *);
> + void *arg;
> +};
>
> - spin_lock(&blockdev_superblock->s_inode_list_lock);
> - list_for_each_entry(inode, &blockdev_superblock->s_inodes, i_sb_list) {
> - struct address_space *mapping = inode->i_mapping;
> +static void __iterate_bdevs(struct inode *inode, void *arg)
> +{
> + struct iterate_bdevs_data *ibd = arg;
>
> - spin_lock(&inode->i_lock);
> - if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW) ||
> - mapping->nrpages == 0) {
> - spin_unlock(&inode->i_lock);
> - continue;
> - }
> - __iget(inode);
> - spin_unlock(&inode->i_lock);
> - spin_unlock(&blockdev_superblock->s_inode_list_lock);
> - /*
> - * We hold a reference to 'inode' so it couldn't have been
> - * removed from s_inodes list while we dropped the
> - * s_inode_list_lock We cannot iput the inode now as we can
> - * be holding the last reference and we cannot iput it under
> - * s_inode_list_lock. So we keep the reference and iput it
> - * later.
> - */
> - iput(old_inode);
> - old_inode = inode;
> + ibd->func(I_BDEV(inode), ibd->arg);
> +}
>
> - func(I_BDEV(inode), arg);
> +static bool __iterate_bdevs_cond(struct inode *inode, void *arg)
> +{
> + return inode->i_mapping->nr_pages != 0;
> +}
>
> - spin_lock(&bl
Re: [PATCH v5.1] phy: rockchip-usb: add handler for usb-uart functionality
Am Montag, 22. Februar 2016, 17:15:34 schrieb Kishon Vijay Abraham I:
> > changes in v5.1:
> > - fix corruptions that happened when sending v5
>
> I still see the corruption.
>
> This is how I see the patch after downloading (from both mutt and
> thunderbird)
interesting ... I see this now too, but "git am" was happy with the encoding
it seems, I did a
git am foo.mbox
git format-patch -1
diff -u new.patch orig.patch
and the result did match (minus the comment section).
Anyway, I'll go with git send-email now ;-)
Sorry about that
Heiko
> @@ -3486,6 +3486,12 @@ bytes respectively. Such letter
> suffixes can also be= entirely omitted.
> =20
> ro [KNL] Mount root device read-only on boot
> =20
> + rockchip.usb_uart
> + Enable the uart passthrough on the designated usb
> port + on Rockchip SoCs. When active, the signals
> of the + debug-uart get routed to the D+ and D-
> pins of the usb + port and the regular usb
> controller gets disabled. +
> root=3D [KNL] Root filesystem
> See name_to_dev_t comment in init/do_mounts.c.
> =20
> diff --git a/drivers/phy/phy-rockchip-usb.c
> b/drivers/phy/phy-rockchip-usb.= c
> index 33a80eb..f62d899 100644
> --- a/drivers/phy/phy-rockchip-usb.c
> +++ b/drivers/phy/phy-rockchip-usb.c
> @@ -30,21 +30,23 @@
> #include
> #include
> =20
> -/*
> - * The higher 16-bit of this register is used for write protection
> - * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
> - */
> -#define SIDDQ_WRITE_ENABIT(29)
> -#define SIDDQ_ON BIT(13)
> -#define SIDDQ_OFF (0 << 13)
> +static int enable_usb_uart;
> +
> +#define HIWORD_UPDATE(val, mask) \
> + ((val) | (mask) << 16)
> +
> +#define UOC_CON0_SIDDQ BIT(13)
> =20
> struct rockchip_usb_phys {
> int reg;
> const char *pll_name;
> };
> =20
>
> .
> .
>
> I didn't see this problem with the other patches I applied today.
>
> Thanks
> Kishon
>
> > changes in v5:
> > - only compile debug uart functionality if the phy is compiled in
> >
> > fixes initcall conflict and debug functionality also is only really
> > usable if it's available early
> >
> > changes in v4:
> > - drop the rest of the phy-series, as the patches have gotten applied
> >
> > So far, this hasn't gotten eyeballs yet, so citing discussion-parts from
> > the v3 coverletter:
> >
> > The patch, while not associated with the new pll handling, also builds
> > on the groundwork introduced there and adds support for the function
> > repurposing one of the phys as passthrough for uart-data. This enables
> > attaching a ttl converter to the D+ and D- pins of an usb cable to
> > receive uart data this way, when it is not really possible to attach
> > a regular serial console to a board.
> >
> > One point of critique in my first iteration [0] of this was, that
> > due to when the reconfiguration happens we may miss parts of the logs
> > when earlycon is enabled. So far early_initcall gets used as the
> > unflattened devicetree is necessary to set this up. Doing this for
> > example in the early_param directly would require parsing the flattened
> > devicetree to get needed nodes and properties.
> >
> > I still maintain that if you're working on anything before smp-bringup
> > you should use a real dev-board instead or try to solder uart cables
> > on hopefully available test-points .
> >
> > Documentation/kernel-parameters.txt | 6 +
> > drivers/phy/phy-rockchip-usb.c | 233
> > ++-- 2 files changed, 203
> > insertions(+), 36 deletions(-)
> >
> > diff --git a/Documentation/kernel-parameters.txt
> > b/Documentation/kernel-parameters.txt index 87d40a7..d91417b 100644
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -3486,6 +3486,12 @@ bytes respectively. Such letter suffixes can also
> > be entirely omitted.>
> > ro [KNL] Mount root device read-only on boot
> >
> > + rockchip.usb_uart
> > + Enable the uart passthrough on the designated usb port
> > + on Rockchip SoCs. When active, the signals of the
> > + debug-uart get routed to the D+ and D- pins of the usb
> > + port and the regular usb controller gets disabled.
> > +
> >
> > root= [KNL] Root filesystem
> >
> > See name_to_dev_t comment in init/do_mounts.c.
> >
> > diff --git a/drivers/phy/phy-rockchip-usb.c
> > b/drivers/phy/phy-rockchip-usb.c index 33a80eb..f62d899 100644
> > --- a/drivers/phy/phy-rockchip-usb.c
> > +++ b/drivers/phy/phy-rockchip-usb.c
> > @@ -30,21 +30,23 @@
> >
> > #include
> > #include
> >
> > -/*
> > - * The higher 16-bit of this register is used for write protection
> > - * only if BIT(13 + 16) set to 1 the BIT(13
Re: [PATCH v2] mm/slab: re-implement pfmemalloc support
On Thu, Feb 11, 2016 at 04:34:47PM +0900, js1...@gmail.com wrote: > From: Joonsoo Kim > > Current implementation of pfmemalloc handling in SLAB has some problems. > Tested-by: Mel Gorman The test completed successfully if a lot slower. However, the time to completion is not reliable anyway and subject to a number of factors so it's not of concern. -- Mel Gorman SUSE Labs
Re: [patch V2 10/28] x86/perf/intel_uncore: Store box in event->pmu_private
On Mon, Feb 22, 2016 at 11:06:50AM -, Thomas Gleixner wrote:
> + event->pmu_private = box;
> +static inline struct intel_uncore_box *uncore_event_to_box(struct perf_event
> *event)
> +{
> + return event->pmu_private;
> +}
Do you really need this? That is, what is wrong with:
static inline struct intel_uncore_box *uncore_event_to_box(struct perf_event
*event)
{
return uncore_pmu_to_box(event->pmu, event->cpu);
}
Which, after patch 12, should be fairly trivial, right?
Re: [PATCH v2 1/2] drm: Improve drm_of_component_probe() to correctly handle ports and remote ports.
On Fri, Nov 20, 2015 at 02:22:04PM +, Liviu Dudau wrote:
> Rockchip DRM driver cannot use the same compare_of() function to
> match ports and remote ports (aka encoders) as their OF sub-trees
> look different. Add a second compare function to be used when encoders
> are added to the component framework and patch the existing users of
> the function accordingly.
>
> Signed-off-by: Liviu Dudau
Russell,
Resurecting this old patch from around Christmas time (bad time for patch
review).
Are you happy enough with this version to re-issue the Ack or do you think I
still
need to work on it?
Best regards,
Liviu
> ---
> drivers/gpu/drm/armada/armada_drv.c | 3 ++-
> drivers/gpu/drm/drm_of.c| 19 ++-
> drivers/gpu/drm/imx/imx-drm-core.c | 3 ++-
> include/drm/drm_of.h| 6 --
> 4 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_drv.c
> b/drivers/gpu/drm/armada/armada_drv.c
> index 77ab93d..3a2a929 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -274,7 +274,8 @@ static int armada_drm_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> int ret;
>
> - ret = drm_of_component_probe(dev, compare_dev_name, &armada_master_ops);
> + ret = drm_of_component_probe(dev, compare_dev_name, compare_dev_name,
> + &armada_master_ops);
> if (ret != -EINVAL)
> return ret;
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 493c05c..34589d3 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -77,7 +77,8 @@ EXPORT_SYMBOL(drm_of_find_possible_crtcs);
> * Returns zero if successful, or one of the standard error codes if it
> fails.
> */
> int drm_of_component_probe(struct device *dev,
> -int (*compare_of)(struct device *, void *),
> +int (*compare_port)(struct device *, void *),
> +int (*compare_encoder)(struct device *, void *),
> const struct component_master_ops *m_ops)
> {
> struct device_node *ep, *port, *remote;
> @@ -101,8 +102,12 @@ int drm_of_component_probe(struct device *dev,
> continue;
> }
>
> - component_match_add(dev, &match, compare_of, port);
> - of_node_put(port);
> + component_match_add(dev, &match, compare_port, port);
> + /*
> + * component_match_add keeps a reference to the port
> + * variable, so we need to keep the reference count
> + * increment from of_parse_phandle()
> + */
> }
>
> if (i == 0) {
> @@ -140,8 +145,12 @@ int drm_of_component_probe(struct device *dev,
> continue;
> }
>
> - component_match_add(dev, &match, compare_of, remote);
> - of_node_put(remote);
> + component_match_add(dev, &match, compare_encoder,
> remote);
> + /*
> + * component_match_add keeps a reference to the port
> + * variable, so we need to keep the reference count
> + * increment from of_graph_get_remote_port_parent()
> + */
> }
> of_node_put(port);
> }
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 64f16ea..0d36410 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -531,7 +531,8 @@ static const struct component_master_ops imx_drm_ops = {
>
> static int imx_drm_platform_probe(struct platform_device *pdev)
> {
> - int ret = drm_of_component_probe(&pdev->dev, compare_of, &imx_drm_ops);
> + int ret = drm_of_component_probe(&pdev->dev, compare_of, compare_of,
> + &imx_drm_ops);
>
> if (!ret)
> ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> index 8544665..1c29e42 100644
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -10,7 +10,8 @@ struct device_node;
> extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> struct device_node *port);
> extern int drm_of_component_probe(struct device *dev,
> - int (*compare_of)(struct device *, void *),
> + int (*compare_port)(struct device *, void *),
> + int (*compare_encoder)(struct device *, void
> *),
> const struct component_master_ops *m_ops);
> #else
> static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> @@ -21,7 +22,8 @@ static inlin
Re: [PATCH v5.1] phy: rockchip-usb: add handler for usb-uart functionality
Hi,
On Monday 22 February 2016 05:11 PM, Heiko Stuebner wrote:
> Most newer Rockchip SoCs provide the possibility to use a usb-phy
> as passthrough for the debug uart (uart2), making it possible to
> for example get console output without needing to open the device.
>
> This patch adds an early_initcall to enable this functionality
> conditionally via the commandline and also disables the corresponding
> usb controller in the devicetree.
>
> Currently only data for the rk3288 is provided, but at least the
> rk3188 and arm64 rk3368 also provide this functionality and will be
> enabled later.
>
> On a spliced usb cable the signals are tx on white wire(D+) and
> rx on green wire(D-).
>
> The one caveat is that currently the reconfiguration of the phy
> happens as early_initcall, as the code depends on the unflattened
> devicetree being available. Everything is fine if only a regular
> console is active as the console-replay will happen after the
> reconfiguation. But with earlycon active output up to smp-init
> currently will get lost.
>
> The phy is an optional property for the connected dwc2 controller,
> so we still provide the phy device but fail all phy-ops with -EBUSY
> to make sure the dwc2 does not try to transmit anything on the
> repurposed phy.
>
> Signed-off-by: Heiko Stuebner
> ---
> changes in v5.1:
> - fix corruptions that happened when sending v5
I still see the corruption.
This is how I see the patch after downloading (from both mutt and thunderbird)
@@ -3486,6 +3486,12 @@ bytes respectively. Such letter suffixes can also be=
entirely omitted.
=20
ro [KNL] Mount root device read-only on boot
=20
+ rockchip.usb_uart
+ Enable the uart passthrough on the designated usb port
+ on Rockchip SoCs. When active, the signals of the
+ debug-uart get routed to the D+ and D- pins of the usb
+ port and the regular usb controller gets disabled.
+
root=3D [KNL] Root filesystem
See name_to_dev_t comment in init/do_mounts.c.
=20
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.=
c
index 33a80eb..f62d899 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -30,21 +30,23 @@
#include
#include
=20
-/*
- * The higher 16-bit of this register is used for write protection
- * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
- */
-#define SIDDQ_WRITE_ENABIT(29)
-#define SIDDQ_ON BIT(13)
-#define SIDDQ_OFF (0 << 13)
+static int enable_usb_uart;
+
+#define HIWORD_UPDATE(val, mask) \
+ ((val) | (mask) << 16)
+
+#define UOC_CON0_SIDDQ BIT(13)
=20
struct rockchip_usb_phys {
int reg;
const char *pll_name;
};
=20
.
.
I didn't see this problem with the other patches I applied today.
Thanks
Kishon
> changes in v5:
> - only compile debug uart functionality if the phy is compiled in
> fixes initcall conflict and debug functionality also is only really
> usable if it's available early
> changes in v4:
> - drop the rest of the phy-series, as the patches have gotten applied
>
> So far, this hasn't gotten eyeballs yet, so citing discussion-parts from
> the v3 coverletter:
>
> The patch, while not associated with the new pll handling, also builds
> on the groundwork introduced there and adds support for the function
> repurposing one of the phys as passthrough for uart-data. This enables
> attaching a ttl converter to the D+ and D- pins of an usb cable to
> receive uart data this way, when it is not really possible to attach
> a regular serial console to a board.
>
> One point of critique in my first iteration [0] of this was, that
> due to when the reconfiguration happens we may miss parts of the logs
> when earlycon is enabled. So far early_initcall gets used as the
> unflattened devicetree is necessary to set this up. Doing this for
> example in the early_param directly would require parsing the flattened
> devicetree to get needed nodes and properties.
>
> I still maintain that if you're working on anything before smp-bringup
> you should use a real dev-board instead or try to solder uart cables
> on hopefully available test-points .
>
>
> Documentation/kernel-parameters.txt | 6 +
> drivers/phy/phy-rockchip-usb.c | 233
> ++--
> 2 files changed, 203 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index 87d40a7..d91417b 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -3486,6 +3486,12 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
>
> ro [KNL] Mount root device read-only on boot
>
> + rockchip.usb_uart
> + Enable the uart passthrough on the designated usb port
> +
Re: [patch V2 10/28] x86/perf/intel_uncore: Store box in event->pmu_private
On Mon, Feb 22, 2016 at 11:06:50AM -, Thomas Gleixner wrote: > Index: b/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c > === > --- a/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c > +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c > @@ -313,6 +313,7 @@ static int snb_uncore_imc_event_init(str > return -EINVAL; > > event->cpu = box->cpu; > + event->pmu_private = pmu; This seems rather pointless, did you want that to be '= box' instead? > > event->hw.idx = -1; > event->hw.last_tag = ~0ULL; > >
[PATCH] clk: qcom: msm8960: fix ce3_core clk enable register
This patch corrects the enable register offset which is actually 0x36cc
instead of 0x36c4
Signed-off-by: Srinivas Kandagatla
---
drivers/clk/qcom/gcc-msm8960.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c
index 063e0f0..d14eae1 100644
--- a/drivers/clk/qcom/gcc-msm8960.c
+++ b/drivers/clk/qcom/gcc-msm8960.c
@@ -2928,7 +2928,7 @@ static struct clk_branch ce3_core_clk = {
.halt_reg = 0x2fdc,
.halt_bit = 5,
.clkr = {
- .enable_reg = 0x36c4,
+ .enable_reg = 0x36cc,
.enable_mask = BIT(4),
.hw.init = &(struct clk_init_data){
.name = "ce3_core_clk",
--
1.9.1
Re: [PATCH v2 2/2] drm/panel: Support for LG lp120up1 panel with eDP input
On Mon, Feb 22, 2016 at 04:42:54PM +0530, sanjeev sharma wrote:
> Hello Jitao,
>
> Can't we add this panel information in device tree file instead inside the
> device driver ?
We could, but that would be redundant. Panels need to be represented by
a specific compatible string anyway, and that compatible string implies
the video timings, bits-per-color, width and height.
Also there's more to panels than just the timings or dimensions. Power
up and power down sequences are also implied by the compatible stirng.
Describing all of that in the device tree was at some point attempted,
but in the end it turned out too complicated and we ended up with what
we have now.
Thierry
> On Mon, Feb 22, 2016 at 4:31 PM, Jitao Shi wrote:
>
> > The LG lp120up1 TFT LCD panel with eDP interface is a 12.0" 1920x1280
> > panel, which can be supported by the simple panel driver
> >
> > Signed-off-by: Jitao Shi
> > ---
> > Changes since v1:
> > - Add eDP panel type in comment msg
> > - Fixed comment msg with 72 characters width
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 26 ++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index f88a631..2030c37 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -982,6 +982,29 @@ static const struct panel_desc lg_lb070wv8 = {
> > .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> > };
> >
> > +static const struct drm_display_mode lg_lp120up1_mode = {
> > + .clock = 162300,
> > + .hdisplay = 1920,
> > + .hsync_start = 1920 + 40,
> > + .hsync_end = 1920 + 40 + 40,
> > + .htotal = 1920 + 40 + 40+ 80,
> > + .vdisplay = 1280,
> > + .vsync_start = 1280 + 4,
> > + .vsync_end = 1280 + 4 + 4,
> > + .vtotal = 1280 + 4 + 4 + 12,
> > + .vrefresh = 60,
> > +};
> > +
> > +static const struct panel_desc lg_lp120up1 = {
> > + .modes = &lg_lp120up1_mode,
> > + .num_modes = 1,
> > + .bpc = 8,
> > + .size = {
> > + .width = 267,
> > + .height = 183,
> > + },
> > +};
> > +
> > static const struct drm_display_mode lg_lp129qe_mode = {
> > .clock = 285250,
> > .hdisplay = 2560,
> > @@ -1256,6 +1279,9 @@ static const struct of_device_id platform_of_match[]
> > = {
> > .compatible = "lg,lb070wv8",
> > .data = &lg_lb070wv8,
> > }, {
> > + .compatible = "lg,lp120up1",
> > + .data = &lg_lp120up1,
> > + }, {
> > .compatible = "lg,lp129qe",
> > .data = &lg_lp129qe,
> > }, {
> > --
> > 1.7.9.5
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
signature.asc
Description: PGP signature
[PATCH] Doc: xtensa : Fix a typo in atomctl.txt
This patch fix a typo found in atomctl.txt Signed-off-by: Masanari Iida --- Documentation/xtensa/atomctl.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/xtensa/atomctl.txt b/Documentation/xtensa/atomctl.txt index 1da783a..80fe006 100644 --- a/Documentation/xtensa/atomctl.txt +++ b/Documentation/xtensa/atomctl.txt @@ -19,7 +19,7 @@ doing a Cached (WB) transaction and use the Memory RCW for un-cached operations. For systems without an coherent cache controller, non-MX, we always -use the memory controllers RCW, thought non-MX controlers likely +use the memory controllers RCW, thought non-MX controllers likely support the Internal Operation. CUSTOMER-WARNING: -- 2.7.1.339.g0233b80
[PATCH v5.1] phy: rockchip-usb: add handler for usb-uart functionality
Most newer Rockchip SoCs provide the possibility to use a usb-phy
as passthrough for the debug uart (uart2), making it possible to
for example get console output without needing to open the device.
This patch adds an early_initcall to enable this functionality
conditionally via the commandline and also disables the corresponding
usb controller in the devicetree.
Currently only data for the rk3288 is provided, but at least the
rk3188 and arm64 rk3368 also provide this functionality and will be
enabled later.
On a spliced usb cable the signals are tx on white wire(D+) and
rx on green wire(D-).
The one caveat is that currently the reconfiguration of the phy
happens as early_initcall, as the code depends on the unflattened
devicetree being available. Everything is fine if only a regular
console is active as the console-replay will happen after the
reconfiguation. But with earlycon active output up to smp-init
currently will get lost.
The phy is an optional property for the connected dwc2 controller,
so we still provide the phy device but fail all phy-ops with -EBUSY
to make sure the dwc2 does not try to transmit anything on the
repurposed phy.
Signed-off-by: Heiko Stuebner
---
changes in v5.1:
- fix corruptions that happened when sending v5
changes in v5:
- only compile debug uart functionality if the phy is compiled in
fixes initcall conflict and debug functionality also is only really
usable if it's available early
changes in v4:
- drop the rest of the phy-series, as the patches have gotten applied
So far, this hasn't gotten eyeballs yet, so citing discussion-parts from
the v3 coverletter:
The patch, while not associated with the new pll handling, also builds
on the groundwork introduced there and adds support for the function
repurposing one of the phys as passthrough for uart-data. This enables
attaching a ttl converter to the D+ and D- pins of an usb cable to
receive uart data this way, when it is not really possible to attach
a regular serial console to a board.
One point of critique in my first iteration [0] of this was, that
due to when the reconfiguration happens we may miss parts of the logs
when earlycon is enabled. So far early_initcall gets used as the
unflattened devicetree is necessary to set this up. Doing this for
example in the early_param directly would require parsing the flattened
devicetree to get needed nodes and properties.
I still maintain that if you're working on anything before smp-bringup
you should use a real dev-board instead or try to solder uart cables
on hopefully available test-points .
Documentation/kernel-parameters.txt | 6 +
drivers/phy/phy-rockchip-usb.c | 233 ++--
2 files changed, 203 insertions(+), 36 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 87d40a7..d91417b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3486,6 +3486,12 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
ro [KNL] Mount root device read-only on boot
+ rockchip.usb_uart
+ Enable the uart passthrough on the designated usb port
+ on Rockchip SoCs. When active, the signals of the
+ debug-uart get routed to the D+ and D- pins of the usb
+ port and the regular usb controller gets disabled.
+
root= [KNL] Root filesystem
See name_to_dev_t comment in init/do_mounts.c.
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
index 33a80eb..f62d899 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -30,21 +30,23 @@
#include
#include
-/*
- * The higher 16-bit of this register is used for write protection
- * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
- */
-#define SIDDQ_WRITE_ENABIT(29)
-#define SIDDQ_ON BIT(13)
-#define SIDDQ_OFF (0 << 13)
+static int enable_usb_uart;
+
+#define HIWORD_UPDATE(val, mask) \
+ ((val) | (mask) << 16)
+
+#define UOC_CON0_SIDDQ BIT(13)
struct rockchip_usb_phys {
int reg;
const char *pll_name;
};
+struct rockchip_usb_phy_base;
struct rockchip_usb_phy_pdata {
struct rockchip_usb_phys *phys;
+ int (*init_usb_uart)(struct regmap *grf);
+ int usb_uart_phy;
};
struct rockchip_usb_phy_base {
@@ -61,13 +63,15 @@ struct rockchip_usb_phy {
struct clk *clk480m;
struct clk_hw clk480m_hw;
struct phy *phy;
+ booluart_enabled;
};
static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
bool siddq)
{
- return regmap_write(phy->base->reg_base, phy->reg_offset,
- SIDDQ_WRITE_ENA | (siddq ? SIDDQ_ON : SIDDQ_OFF));
+ u32 val = HIWORD_UPDATE(s
Re: [Eas-dev] [PATCH] cpufreq_sched: set governor_data before waking up kschedfreq
On 22/02/16 19:32, Pingbo Wen wrote: > Hi, Juri > > On Monday, February 22, 2016 06:53 PM, Juri Lelli wrote: > > Hi, > > > > On 20/02/16 19:32, Pingbo Wen wrote: > >> Fix null pointer dereference error liked below. This BUG can be easily > >> re-produced by 'monkey --throttle 50' in android 6.0. > >> > > > > I'm not sure which code base you are looking at here, but I think this > > problem has already been noticed and fixed by Ricky. Thanks for sharing > > your fix, though. > > I pulled git://linux-arm.org/linux-power.git origin/energy_model_rfc_v5.2, > but didn't get any new commits about this bug. Where can I find the latest > branch? > The fix is not yet present in any branch, but I think it has been already discussed in Steve's last RFC. I guess it will be incorporated in his next version. Best, - Juri
[PATCH 3/3] Btrfs: disk-io: fixed a comment block coding style issue
Makes the comment block start with /* on a separate line, and end with */ on a separate line as well. Signed-off-by: Philippe Loctaux --- fs/btrfs/disk-io.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index f642b30..2545d01 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -4416,9 +4416,9 @@ void btrfs_cleanup_one_transaction(struct btrfs_transaction *cur_trans, wake_up(&cur_trans->commit_wait); /* - memset(cur_trans, 0, sizeof(*cur_trans)); - kmem_cache_free(btrfs_transaction_cachep, cur_trans); - */ +* memset(cur_trans, 0, sizeof(*cur_trans)); +* kmem_cache_free(btrfs_transaction_cachep, cur_trans); +*/ } static int btrfs_cleanup_transaction(struct btrfs_root *root) -- 2.7.1
Re: [PATCH 6/6] arm64: compat: Check for AArch32 state
On 09/02/16 17:36, Will Deacon wrote:
On Thu, Jan 28, 2016 at 11:32:17AM +, Suzuki K Poulose wrote:
Make sure we have AArch32 state available for running COMPAT binaries.
*/
seq_puts(m, "Features\t:");
- if (personality(current->personality) == PER_LINUX32) {
+ if (system_supports_32bit_el0() &&
+ personality(current->personality) == PER_LINUX32) {
Wouldn't it be better to prevent tasks changing to the PER_LINUX32
personality on systems that don't support AArch32 at EL0?
Yes, thats the ideal solution. I took a look at it and it requires us to
hook in arm64 wrapper for the personality syscall. I will take a look.
Thanks
Suzuki
Re: [PATCH 0/6] ARM: decompressor: several cleanups
On Mon, Feb 22, 2016 at 04:31:11PM +0900, Masahiro Yamada wrote: > Masahiro Yamada (6): > ARM: decompressor: drop unneeded assignments to "targets" > ARM: decompressor: drop more unneeded assignments to "targets" > ARM: decompressor: use clean-files instead of extra-y to clean files > ARM: decompressor: drop redundant FORCE in Makefile > ARM: decompressor: merge piggy.*.S and simplify Makefile > ARM: decompressor: rename suffix_y to compress-y Most of this looks fine to me, but I've a question about how thoroughly patch 5 has been tested: iow, do we get correct behaviour if only the compression method is changed? Thanks. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH][V2] rtlwifi: pass struct rtl_stats by reference as it is more efficient
From: Colin Ian King
passing rtl_stats by value is inefficient; the structure is over 300
bytes in size and generally just one field (packet_report_type)
is being accessed, so the pass by value is a relatively large overhead.
This change just affects just the rx_command_packet calls.
Signed-off-by: Colin Ian King
---
drivers/net/wireless/realtek/rtlwifi/pci.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 6 +++---
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.h | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 4 ++--
drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.h | 2 +-
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 4 ++--
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.h | 2 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 2 +-
12 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 7f471bf..4153e7f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -855,7 +855,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
}
/* handle command packet here */
if (rtlpriv->cfg->ops->rx_command_packet &&
- rtlpriv->cfg->ops->rx_command_packet(hw, stats, skb)) {
+ rtlpriv->cfg->ops->rx_command_packet(hw, &stats, skb)) {
dev_kfree_skb_any(skb);
goto new_trx_end;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
index 791efbe..1170106 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
@@ -851,7 +851,7 @@ void rtl88ee_tx_polling(struct ieee80211_hw *hw, u8
hw_queue)
}
u32 rtl88ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ const struct rtl_stats *status,
struct sk_buff *skb)
{
return 0;
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
index eab5ae0..5a24d19 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
@@ -790,7 +790,7 @@ void rtl88ee_tx_fill_cmddesc(struct ieee80211_hw *hw, u8
*pdesc,
bool firstseg, bool lastseg,
struct sk_buff *skb);
u32 rtl88ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ const struct rtl_stats *status,
struct sk_buff *skb);
#endif
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
index d39ee67..24eff8e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
@@ -1105,13 +1105,13 @@ void rtl92ee_tx_polling(struct ieee80211_hw *hw, u8
hw_queue)
}
u32 rtl92ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ const struct rtl_stats *status,
struct sk_buff *skb)
{
u32 result = 0;
struct rtl_priv *rtlpriv = rtl_priv(hw);
- switch (status.packet_report_type) {
+ switch (status->packet_report_type) {
case NORMAL_RX:
result = 0;
break;
@@ -1121,7 +1121,7 @@ u32 rtl92ee_rx_command_packet(struct ieee80211_hw *hw,
break;
default:
RT_TRACE(rtlpriv, COMP_RECV, DBG_TRACE,
-"Unknown packet type %d\n", status.packet_report_type);
+"Unknown packet type %d\n",
status->packet_report_type);
break;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
index 8f78ac9..a4c3834 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
@@ -857,6 +857,6 @@ void rtl92ee_tx_fill_cmddesc(struct ieee80211_hw *hw, u8
*pdesc,
bool firstseg, bool lastseg,
struct sk_buff *skb);
u32 rtl92ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ const struct rtl_stats *status,
