* Re: [RFC PATCH v2 0/8] Add support for Legacy Hdmi audio
From: Mark Brown @ 2016-11-09 13:19 UTC (permalink / raw)
To: Pierre-Louis Bossart; +Cc: Takashi Iwai, intel-gfx, Rakesh A Ughreja
In-Reply-To: <d51d25f1-8bb2-961b-9677-8335ad4a4a29@linux.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1068 bytes --]
On Sun, Nov 06, 2016 at 11:42:31PM -0700, Pierre-Louis Bossart wrote:
> I am all for convergence when it makes sense but I don't see how
> hdmi-codec.h provides equivalent functionality for BYT/CHT with what was
> suggested in this patchset -derived from VED patches- and discussed earlier
> with intel-gfx folks, specifically how LPE pipe interrupts are
> masked/unmasked and passed to the audio driver? The BYT/CHT HDMI
Without knowing what these things are it's hard to comment but it does
seem that if Intel has a reasonable use case for them then so too will
other vendors at some point.
> functionality is also not modeled as an ASoC codec - which seems a
> dependency from the comments in hdmi-codec.h - since it's really part of the
> i915 hardware and exposed only as a set of registers+DMA, without any serial
> link interface typically needed for an external device or the internal
> HDAudio-display link.
None of which is at all unusal. The Intel hardware really doesn't seem
like the sort of special snowflake that people appear to believe it to
be.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c
From: Adrian Hunter @ 2016-11-09 14:01 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Arnaldo Carvalho de Melo
Cc: Andi Kleen, linux-kernel, Andi Kleen
In-Reply-To: <20161109135927.GE12125@kernel.org>
On 09/11/16 15:59, Arnaldo Carvalho de Melo wrote:
> Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu:
>>> From: Andi Kleen <ak@linux.intel.com>
>>>
>>> Since the unprivileged sched switch event was added in perf,
>>> PT doesn't need need perf_event_paranoid=-1 anymore for
>>> per cpu decoding. So remove the obsolete paragraph in
>>> the documentation.
>>
>> Thanks for pointing that out, I'll do something slightly different tho,
>> pointing out that from kernel X.Y.Z, when the unprivileged
>> PERF_RECORD_SWITCH metadata event was introduced, this is no longer an
>> issue, having to be considered only on older kernels.
>
> It ended up as:
>
> diff --git a/tools/perf/Documentation/intel-pt.txt b/tools/perf/Documentation/intel-pt.txt
> index c6c8318e38a2..4d12db118476 100644
> --- a/tools/perf/Documentation/intel-pt.txt
> +++ b/tools/perf/Documentation/intel-pt.txt
> @@ -546,6 +546,18 @@ mode by using the --per-thread option.
> Privileged vs non-privileged users
> ----------------------------------
>
> +The v4.2 kernel introduced support for a context switch metadata event,
> +PERF_RECORD_SWITCH, which allows unprivileged users to see when their processes
> +are scheduled out and in, just not by whom, which is left for the
> +PERF_RECORD_SWITCH_CPU_WIDE, that is only accessible in system wide context,
> +which in turn requires CAP_SYS_ADMIN.
> +
> +Please see the 45ac1403f564 ("perf: Add PERF_RECORD_SWITCH to indicate context
> +switches") commit, that introduces these metadata events for further info.
> +
> +When working with kernels < v4.2, the following considerations must be taken,
> +as the sched:sched_switch tracepoints will be used to receive such information:
> +
> Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
> have memory limits imposed upon them. That affects what buffer sizes they can
> have as outlined above.
Maybe put that last paragraph about memory limits above the new text.
^ permalink raw reply
* Re: [PATCH v2] spi: rspi: rewrites the name of the function
From: Mark Brown @ 2016-11-09 14:05 UTC (permalink / raw)
To: Cao Minh Hiep
Cc: geert+renesas, linux-spi, kuninori.morimoto.gx,
yoshihiro.shimoda.uh, ryusuke.sakato.bx, linux-renesas-soc,
nv-dung, h-inayoshi
In-Reply-To: <1478565346-4320-1-git-send-email-cm-hiep@jinso.co.jp>
[-- Attachment #1: Type: text/plain, Size: 258 bytes --]
On Tue, Nov 08, 2016 at 09:35:46AM +0900, Cao Minh Hiep wrote:
> From: Hiep Cao Minh <cm-hiep@jinso.co.jp>
>
> This patch rewrites the name of rspi_pio_transfer_in_or_out
> function.
This doesn't apply against current code, please check and resend.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
From: Jan Beulich @ 2016-11-09 14:05 UTC (permalink / raw)
To: Razvan Cojocaru, Andrew Cooper
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, xen-devel,
julien.grall, tamas, jun.nakajima, boris.ostrovsky
In-Reply-To: <024e9839-9f23-188e-7f7d-98029b780208@citrix.com>
>>> On 09.11.16 at 12:49, <andrew.cooper3@citrix.com> wrote:
> On 09/11/16 11:32, Razvan Cojocaru wrote:
>> On 11/09/2016 01:17 PM, Jan Beulich wrote:
>>>>>> On 09.11.16 at 10:42, <rcojocaru@bitdefender.com> wrote:
>>>> @@ -259,6 +266,13 @@ struct vm_event_cpuid {
>>>> uint32_t _pad;
>>>> };
>>>>
>>>> +struct vm_event_interrupt {
>>>> + uint32_t vector;
>>>> + uint32_t type;
>>>> + uint32_t error_code;
>>>> + uint64_t cr2;
>>>> +};
>>> This being x86-specific, I think it should be named or union-ized
>>> accordingly.
>> Right, I'll rename it.
>
> You area also exposing X86_EVENTTYPE_* in the hypervisor ABI.
>
> This is probably fine as it is an ABI inherited from VT-x/SVM (and by
> some miracle, are actually compatible), but you do need to move the
> constants into the public API as well.
I was about to make that comment too, but then checked: These
constants are already exposed (via the inject trap hypercall). While
moving them into the public header might be a good idea in general,
I don't think that belongs into this patch.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
From: Razvan Cojocaru @ 2016-11-09 14:05 UTC (permalink / raw)
To: Jan Beulich
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
In-Reply-To: <58233AEE020000780011D5F5@prv-mh.provo.novell.com>
On 11/09/2016 04:04 PM, Jan Beulich wrote:
>>>> On 09.11.16 at 12:32, <rcojocaru@bitdefender.com> wrote:
>> On 11/09/2016 01:17 PM, Jan Beulich wrote:
>>>>>> On 09.11.16 at 10:42, <rcojocaru@bitdefender.com> wrote:
>>>> --- a/xen/arch/x86/hvm/hvm.c
>>>> +++ b/xen/arch/x86/hvm/hvm.c
>>>> @@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
>>>> }
>>>> }
>>>>
>>>> - /* Inject pending hw/sw trap */
>>>> - if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>>>> - {
>>>> + /* Inject pending hw/sw trap if there are no other pending interrupts. */
>>>> + if ( v->arch.hvm_vcpu.inject_trap.vector != -1 && !hvm_event_pending(v) )
>>>> hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
>>>> - v->arch.hvm_vcpu.inject_trap.vector = -1;
>>>> +
>>>> + v->arch.hvm_vcpu.inject_trap.vector = -1;
>>>
>>> I don't see why you pull this out of the if() body.
>>
>> That is intended, and covered by the "the patch also fixes the behaviour
>> of the xc_hvm_inject_trap() hypercall, which would lead to
>> non-architectural interrupts overwriting pending (specifically
>> reinjected) architectural ones" part of the patch description.
>>
>> If we couldn't inject the trap because there was a pending event (i.e.
>> the second if() condition, then not setting
>> v->arch.hvm_vcpu.inject_trap.vector to -1 would lead to the trap being
>> kept for injection at the first opportunity - and that could be when the
>> context has changed and we shouldn't inject it anymore. So
>> v->arch.hvm_vcpu.inject_trap.vector is therefore reset either way.
>
> Ah, that's because you extend the condition. How about you leave
> the condition as is, and only make the actual call conditonal
> upon hvm_event_pending()'s return value? That's also make the
> patch better readable.
Of course, no problem.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v2] spi: rspi: rewrites the name of the function
From: Mark Brown @ 2016-11-09 14:05 UTC (permalink / raw)
To: Cao Minh Hiep
Cc: geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ,
yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ,
ryusuke.sakato.bx-zM6kxYcvzFBBDgjK7y7TUQ,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
nv-dung-HEF513clHfp3+QwDJ9on6Q, h-inayoshi-HEF513clHfp3+QwDJ9on6Q
In-Reply-To: <1478565346-4320-1-git-send-email-cm-hiep-HEF513clHfp3+QwDJ9on6Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 286 bytes --]
On Tue, Nov 08, 2016 at 09:35:46AM +0900, Cao Minh Hiep wrote:
> From: Hiep Cao Minh <cm-hiep-HEF513clHfp3+QwDJ9on6Q@public.gmane.org>
>
> This patch rewrites the name of rspi_pio_transfer_in_or_out
> function.
This doesn't apply against current code, please check and resend.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH] of/irq: improve error message on irq discovery process failure
From: Guilherme G. Piccoli @ 2016-11-09 14:05 UTC (permalink / raw)
To: devicetree; +Cc: linuxppc-dev, linux-pci, frowand.list, robh+dt, gpiccoli
On PowerPC machines some PCI slots might not have Level-triggered
interrupts capability (also know as Level Signaled Interrupts - LSI),
leading of_irq_parse_pci() to complain by presenting error messages
on the kernel log - in this case, the properties "interrupt-map" and
"interrupt-map-mask" are not present on the device's node on device
tree.
This patch introduces a different message for this specific case,
and it also reduces the level of the message from error to warning.
Before this patch, when an adapter was plugged in a slot without Level
interrupts capabilities, we saw generic error messages like this:
[54.239] pci 002d:70:00.0: of_irq_parse_pci() failed with rc=-22
Now, with this applied, we see the following specific message:
[19.947] pci 0014:60:00.0: of_irq_parse_pci() gave up. The slot of this
device has no Level-triggered Interrupts capability.
No functional changes were introduced.
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
---
drivers/of/irq.c | 5 ++++-
drivers/of/of_pci_irq.c | 8 +++++++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 393fea8..1ad6882 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -275,7 +275,10 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
of_node_put(ipar);
of_node_put(newpar);
- return -EINVAL;
+ /* Positive non-zero return means no Level-triggered Interrupts
+ * capability was found.
+ */
+ return ENOENT;
}
EXPORT_SYMBOL_GPL(of_irq_parse_raw);
diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
index 2306313..9b6f387 100644
--- a/drivers/of/of_pci_irq.c
+++ b/drivers/of/of_pci_irq.c
@@ -89,8 +89,14 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq
laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
laddr[1] = laddr[2] = cpu_to_be32(0);
rc = of_irq_parse_raw(laddr, out_irq);
- if (rc)
+
+ if (rc < 0) {
goto err;
+ } else if (rc > 0) {
+ dev_warn(&pdev->dev,
+ "of_irq_parse_pci() gave up. The slot of this device has no Level-triggered Interrupts capability.\n");
+ return -rc;
+ }
return 0;
err:
dev_err(&pdev->dev, "of_irq_parse_pci() failed with rc=%d\n", rc);
--
2.1.0
^ permalink raw reply related
* [PATCH 11/13] ARM: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
From: Heiko Stuebner @ 2016-11-09 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103062135.10697-12-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:33 CET schrieb Jaehoon Chung:
> In drivers/mmc/core/host.c, there is "max-frequency" property.
> It should be same behavior. So use the "max-frequency" instead of
> "clock-freq-min-max".
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
looks good, my veyron-pinky and rk3036-kylin still seem to work and hopefully
I haven't missed any spelling errors in the properties :-), so applied to my
dts32 branch for 4.10
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH 11/13] ARM: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"
From: Heiko Stuebner @ 2016-11-09 14:05 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-rockchip, ulf.hansson, robh+dt, krzk,
shawn.lin
In-Reply-To: <20161103062135.10697-12-jh80.chung@samsung.com>
Am Donnerstag, 3. November 2016, 15:21:33 CET schrieb Jaehoon Chung:
> In drivers/mmc/core/host.c, there is "max-frequency" property.
> It should be same behavior. So use the "max-frequency" instead of
> "clock-freq-min-max".
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
looks good, my veyron-pinky and rk3036-kylin still seem to work and hopefully
I haven't missed any spelling errors in the properties :-), so applied to my
dts32 branch for 4.10
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
From: Jan Beulich @ 2016-11-09 14:04 UTC (permalink / raw)
To: Razvan Cojocaru
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
In-Reply-To: <f36b5905-f796-93f0-86ad-e73c5b3c2e26@bitdefender.com>
>>> On 09.11.16 at 12:32, <rcojocaru@bitdefender.com> wrote:
> On 11/09/2016 01:17 PM, Jan Beulich wrote:
>>>>> On 09.11.16 at 10:42, <rcojocaru@bitdefender.com> wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -532,11 +532,23 @@ void hvm_do_resume(struct vcpu *v)
>>> }
>>> }
>>>
>>> - /* Inject pending hw/sw trap */
>>> - if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>>> - {
>>> + /* Inject pending hw/sw trap if there are no other pending interrupts. */
>>> + if ( v->arch.hvm_vcpu.inject_trap.vector != -1 && !hvm_event_pending(v) )
>>> hvm_inject_trap(&v->arch.hvm_vcpu.inject_trap);
>>> - v->arch.hvm_vcpu.inject_trap.vector = -1;
>>> +
>>> + v->arch.hvm_vcpu.inject_trap.vector = -1;
>>
>> I don't see why you pull this out of the if() body.
>
> That is intended, and covered by the "the patch also fixes the behaviour
> of the xc_hvm_inject_trap() hypercall, which would lead to
> non-architectural interrupts overwriting pending (specifically
> reinjected) architectural ones" part of the patch description.
>
> If we couldn't inject the trap because there was a pending event (i.e.
> the second if() condition, then not setting
> v->arch.hvm_vcpu.inject_trap.vector to -1 would lead to the trap being
> kept for injection at the first opportunity - and that could be when the
> context has changed and we shouldn't inject it anymore. So
> v->arch.hvm_vcpu.inject_trap.vector is therefore reset either way.
Ah, that's because you extend the condition. How about you leave
the condition as is, and only make the actual call conditonal
upon hvm_event_pending()'s return value? That's also make the
patch better readable.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v4 9/9] selinux: Add a cache for quicker retreival of PKey SIDs
From: Daniel Jurgens @ 2016-11-09 14:03 UTC (permalink / raw)
To: Leon Romanovsky
Cc: chrisw@sous-sol.org, paul@paul-moore.com, sds@tycho.nsa.gov,
eparis@parisplace.org, dledford@redhat.com, sean.hefty@intel.com,
hal.rosenstock@gmail.com, selinux@tycho.nsa.gov,
linux-security-module@vger.kernel.org, linux-rdma@vger.kernel.org,
Yevgeny Petrilin, Liran Liss
In-Reply-To: <20161109070455.GF27883@leon.nu>
On 11/9/2016 1:05 AM, Leon Romanovsky wrote:
> On Tue, Nov 08, 2016 at 11:06:25PM +0200, Dan Jurgens wrote:
>> From: Daniel Jurgens <danielj@mellanox.com>
>>
>> It is likely that the SID for the same PKey will be requested many
>> times. To reduce the time to modify QPs and process MADs use a cache to
>> store PKey SIDs.
>>
>> This code is heavily based on the "netif" and "netport" concept
>> originally developed by James Morris <jmorris@redhat.com> and Paul Moore
>> <paul@paul-moore.com> (see security/selinux/netif.c and
>> security/selinux/netport.c for more information)
>>
>> issue: 736423
>> Change-Id: I176c3079d5d84d06839b4f750100ac47a6081e94
> It doesn't belong to commit message.
>
>> Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
Yes, sorry silly oversight on my part. I will address for all patches in v5.
^ permalink raw reply
* Re: [PATCH v4 9/9] selinux: Add a cache for quicker retreival of PKey SIDs
From: Daniel Jurgens @ 2016-11-09 14:03 UTC (permalink / raw)
To: Leon Romanovsky
Cc: chrisw-69jw2NvuJkxg9hUCZPvPmw@public.gmane.org,
paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org,
sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org,
eparis-FjpueFixGhCM4zKIHC2jIg@public.gmane.org,
dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
hal.rosenstock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org,
linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Yevgeny Petrilin, Liran Liss
In-Reply-To: <20161109070455.GF27883@leon.nu>
On 11/9/2016 1:05 AM, Leon Romanovsky wrote:
> On Tue, Nov 08, 2016 at 11:06:25PM +0200, Dan Jurgens wrote:
>> From: Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>
>> It is likely that the SID for the same PKey will be requested many
>> times. To reduce the time to modify QPs and process MADs use a cache to
>> store PKey SIDs.
>>
>> This code is heavily based on the "netif" and "netport" concept
>> originally developed by James Morris <jmorris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> and Paul Moore
>> <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org> (see security/selinux/netif.c and
>> security/selinux/netport.c for more information)
>>
>> issue: 736423
>> Change-Id: I176c3079d5d84d06839b4f750100ac47a6081e94
> It doesn't belong to commit message.
>
>> Signed-off-by: Daniel Jurgens <danielj-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Yes, sorry silly oversight on my part. I will address for all patches in v5.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] regulator: rn5t618: add RC5T619 PMIC support
From: Mark Brown @ 2016-11-09 14:02 UTC (permalink / raw)
To: Pierre-Hugues Husson
Cc: lee.jones, robh+dt, mark.rutland, lgirdwood, devicetree,
linux-kernel
In-Reply-To: <20161105161925.14910-3-phh@phh.me>
[-- Attachment #1: Type: text/plain, Size: 234 bytes --]
On Sat, Nov 05, 2016 at 05:19:25PM +0100, Pierre-Hugues Husson wrote:
> Extend the driver to support Ricoh RC5T619.
> Support the additional regulators and slightly different voltage ranges.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] regulator: rn5t618: add RC5T619 PMIC support
From: Mark Brown @ 2016-11-09 14:02 UTC (permalink / raw)
To: Pierre-Hugues Husson
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161105161925.14910-3-phh-8tEavu1zA38@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 263 bytes --]
On Sat, Nov 05, 2016 at 05:19:25PM +0100, Pierre-Hugues Husson wrote:
> Extend the driver to support Ricoh RC5T619.
> Support the additional regulators and slightly different voltage ranges.
Acked-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH] usb: ehci-omap: don't complain on -EPROBE_DEFER when no PHY found
From: Ladislav Michl @ 2016-11-09 14:02 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Don't complain on -EPROBE_DEFER when when no PHY found, the driver
probe will be retried later.
Signed-off-by: Ladislav Michl <ladis-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
---
drivers/usb/host/ehci-omap.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 94ea9ff..44945eb 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -181,8 +181,9 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
continue;
ret = PTR_ERR(phy);
- dev_err(dev, "Can't get PHY device for port %d: %d\n",
- i, ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Can't get PHY device for port "
+ "%d: %d\n", i, ret);
goto err_phy;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [drm-intel:topic/drm-misc 1/2] backtracetest.c:undefined reference to `save_stack_trace'
From: kbuild test robot @ 2016-11-09 14:01 UTC (permalink / raw)
To: Chris Wilson; +Cc: Daniel Vetter, intel-gfx, kbuild-all, dri-devel
[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: 77d150b90d58ae6a43bf67af28feb26384d06cd6
commit: cd456f8d06d2036e1e013136c3fbf5721d04f6d7 [1/2] drm: Restrict stackdepot usage to builtin drm.ko
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout cd456f8d06d2036e1e013136c3fbf5721d04f6d7
# save the attached .config to linux build tree
make.cross ARCH=m68k
All errors (new ones prefixed by >>):
kernel/built-in.o: In function `backtrace_regression_test':
>> backtracetest.c:(.text+0x550d4): undefined reference to `save_stack_trace'
mm/built-in.o: In function `set_track':
slub.c:(.text+0x41414): undefined reference to `save_stack_trace'
drivers/built-in.o: In function `save_stack.isra.7':
>> drm_mm.c:(.text+0x16be82): undefined reference to `save_stack_trace'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38611 bytes --]
[-- Attachment #3: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH] sound: soc-core: make kernel complaints on -EPROBE_DEFER dev_dbg
From: Ladislav Michl @ 2016-11-09 14:00 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown; +Cc: alsa-devel
There is no point having these complaints to be dev_err as
they are just adding noise to bootlog.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
sound/soc/soc-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index c0bbcd9..8a6ec52 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1013,7 +1013,7 @@ static int soc_bind_dai_link(struct snd_soc_card *card,
cpu_dai_component.dai_name = dai_link->cpu_dai_name;
rtd->cpu_dai = snd_soc_find_dai(&cpu_dai_component);
if (!rtd->cpu_dai) {
- dev_err(card->dev, "ASoC: CPU DAI %s not registered\n",
+ dev_dbg(card->dev, "ASoC: CPU DAI %s not registered\n",
dai_link->cpu_dai_name);
goto _err_defer;
}
@@ -1025,7 +1025,7 @@ static int soc_bind_dai_link(struct snd_soc_card *card,
for (i = 0; i < rtd->num_codecs; i++) {
codec_dais[i] = snd_soc_find_dai(&codecs[i]);
if (!codec_dais[i]) {
- dev_err(card->dev, "ASoC: CODEC DAI %s not registered\n",
+ dev_dbg(card->dev, "ASoC: CODEC DAI %s not registered\n",
codecs[i].dai_name);
goto _err_defer;
}
@@ -1054,7 +1054,7 @@ static int soc_bind_dai_link(struct snd_soc_card *card,
rtd->platform = platform;
}
if (!rtd->platform) {
- dev_err(card->dev, "ASoC: platform %s not registered\n",
+ dev_dbg(card->dev, "ASoC: platform %s not registered\n",
dai_link->platform_name);
goto _err_defer;
}
--
2.1.4
^ permalink raw reply related
* [Buildroot] [PATCH v2] qt5webkit: Get sources from Qt-5-unofficial-builds
From: Alexey Brodkin @ 2016-11-09 13:59 UTC (permalink / raw)
To: buildroot
Instead of messing with git we may get tarballs of obsolete but still
existing submodules as we used to but from a bit different location.
It turned out Qt people still create packages for obsolete submodules
for so-called "unofficial builds", see [1].
[1] https://wiki.qt.io/Qt-5-unofficial-builds
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Seiderer <ps.report@gmx.net>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Julien Corjon <corjon.j@ecagroup.com>
Cc: Gary Bisson <gary.bisson@boundarydevices.com>
Cc: J?r?me Pouiller <jezz@sysmic.org>
---
Changes v1 -> v2:
* Fixes copy-pasted QT5WEBKIT_VERSION
(was QT5WEBKIT_EXAMPLES_VERSION)
Thanks to J?r?me!
package/qt5/qt5.mk | 1 +
package/qt5/qt5webkit/qt5webkit.hash | 4 ++--
package/qt5/qt5webkit/qt5webkit.mk | 14 +++-----------
3 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/package/qt5/qt5.mk b/package/qt5/qt5.mk
index d25f663662ee..e937e234b596 100644
--- a/package/qt5/qt5.mk
+++ b/package/qt5/qt5.mk
@@ -1,6 +1,7 @@
QT5_VERSION_MAJOR = 5.6
QT5_VERSION = $(QT5_VERSION_MAJOR).2
QT5_SITE = http://download.qt.io/official_releases/qt/$(QT5_VERSION_MAJOR)/$(QT5_VERSION)/submodules
+QT5_SNAPSHOTS_SITE = http://download.qt.io/snapshots/qt/$(QT5_VERSION_MAJOR)/$(QT5_VERSION)/latest_src/submodules
include $(sort $(wildcard package/qt5/*/*.mk))
define QT5_LA_PRL_FILES_FIXUP
diff --git a/package/qt5/qt5webkit/qt5webkit.hash b/package/qt5/qt5webkit/qt5webkit.hash
index 96b8bdd6909a..309f776b3ff3 100644
--- a/package/qt5/qt5webkit/qt5webkit.hash
+++ b/package/qt5/qt5webkit/qt5webkit.hash
@@ -1,2 +1,2 @@
-# locally computed
-sha256 bdd659573e7e75cd4ad57b7160a7353d98d21a6fef06e4fb9e114a5b1f1e9dab qt5webkit-b35917bcb44d7f200af0f4ac68a126fa0aa8d93d.tar.gz
+# Hash from: http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/submodules/qtwebkit-opensource-src-5.6.2.tar.xz.mirrorlist
+sha256 528a6b8b1c5095367b26e8ce4f3a46bb739e2e9913ff4dfc6ef58a04fcd73966 qtwebkit-opensource-src-5.6.2.tar.xz
diff --git a/package/qt5/qt5webkit/qt5webkit.mk b/package/qt5/qt5webkit/qt5webkit.mk
index 378cdf78573e..980d2aff0167 100644
--- a/package/qt5/qt5webkit/qt5webkit.mk
+++ b/package/qt5/qt5webkit/qt5webkit.mk
@@ -4,10 +4,9 @@
#
################################################################################
-QT5WEBKIT_VERSION = b35917bcb44d7f200af0f4ac68a126fa0aa8d93d
-# Using GitHub since it supports downloading tarballs from random commits.
-# The http://code.qt.io/cgit/qt/qtwebkit.git/ repo doesn't allow to do so.
-QT5WEBKIT_SITE = $(call github,qtproject,qtwebkit,$(QT5WEBKIT_VERSION))
+QT5WEBKIT_VERSION = $(QT5_VERSION)
+QT5WEBKIT_SITE = $(QT5_SNAPSHOTS_SITE)
+QT5WEBKIT_SOURCE = qtwebkit-opensource-src-$(QT5WEBKIT_VERSION).tar.xz
QT5WEBKIT_DEPENDENCIES = \
host-bison host-flex host-gperf host-python host-ruby \
qt5base sqlite
@@ -43,14 +42,7 @@ define QT5WEBKIT_PYTHON2_SYMLINK
endef
QT5WEBKIT_PRE_CONFIGURE_HOOKS += QT5WEBKIT_PYTHON2_SYMLINK
-# Since we get the source from git, generated header files are not included.
-# qmake detects that header file generation (using the syncqt tool) must be
-# done based on the existence of a .git directory (cfr. the git_build config
-# option which is set in qt_build_paths.prf).
-# So, to make sure that qmake detects that header files must be generated,
-# create an empty .git directory.
define QT5WEBKIT_CONFIGURE_CMDS
- mkdir -p $(@D)/.git
(cd $(@D); $(TARGET_MAKE_ENV) $(QT5WEBKIT_ENV) $(HOST_DIR)/usr/bin/qmake)
endef
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c
From: Arnaldo Carvalho de Melo @ 2016-11-09 13:59 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Andi Kleen, linux-kernel, Andi Kleen, adrian.hunter
In-Reply-To: <20161109131426.GD12125@kernel.org>
Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu:
> > From: Andi Kleen <ak@linux.intel.com>
> >
> > Since the unprivileged sched switch event was added in perf,
> > PT doesn't need need perf_event_paranoid=-1 anymore for
> > per cpu decoding. So remove the obsolete paragraph in
> > the documentation.
>
> Thanks for pointing that out, I'll do something slightly different tho,
> pointing out that from kernel X.Y.Z, when the unprivileged
> PERF_RECORD_SWITCH metadata event was introduced, this is no longer an
> issue, having to be considered only on older kernels.
It ended up as:
diff --git a/tools/perf/Documentation/intel-pt.txt b/tools/perf/Documentation/intel-pt.txt
index c6c8318e38a2..4d12db118476 100644
--- a/tools/perf/Documentation/intel-pt.txt
+++ b/tools/perf/Documentation/intel-pt.txt
@@ -546,6 +546,18 @@ mode by using the --per-thread option.
Privileged vs non-privileged users
----------------------------------
+The v4.2 kernel introduced support for a context switch metadata event,
+PERF_RECORD_SWITCH, which allows unprivileged users to see when their processes
+are scheduled out and in, just not by whom, which is left for the
+PERF_RECORD_SWITCH_CPU_WIDE, that is only accessible in system wide context,
+which in turn requires CAP_SYS_ADMIN.
+
+Please see the 45ac1403f564 ("perf: Add PERF_RECORD_SWITCH to indicate context
+switches") commit, that introduces these metadata events for further info.
+
+When working with kernels < v4.2, the following considerations must be taken,
+as the sched:sched_switch tracepoints will be used to receive such information:
+
Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
have memory limits imposed upon them. That affects what buffer sizes they can
have as outlined above.
^ permalink raw reply related
* RE: [PATCH xf86-video-ati 2/2] Use pRADEONEnt to find both screens of a GPU in radeon_mode_hotplug
From: Deucher, Alexander @ 2016-11-09 13:58 UTC (permalink / raw)
To: 'Michel Dänzer',
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
In-Reply-To: <20161109071700.24235-2-michel-otUistvHUpPR7s880joybQ@public.gmane.org>
> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Michel Dänzer
> Sent: Wednesday, November 09, 2016 2:17 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH xf86-video-ati 2/2] Use pRADEONEnt to find both screens of
> a GPU in radeon_mode_hotplug
>
> From: Michel Dänzer <michel.daenzer@amd.com>
>
> Fixes misbehaviour when hotplugging DisplayPort connectors on secondary
> GPUs.
>
> Fixes: c801f9f10a5d ("Handle Zaphod mode correctly in
> radeon_mode_hotplug")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98626
> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Series is:
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> src/drmmode_display.c | 23 ++++++++---------------
> src/radeon_kms.c | 5 +++++
> src/radeon_probe.h | 2 ++
> 3 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index fd5c80e..070979d 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> @@ -2580,7 +2580,7 @@ radeon_mode_hotplug(ScrnInfoPtr scrn,
> drmmode_ptr drmmode)
> xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(scrn);
> RADEONEntPtr pRADEONEnt = RADEONEntPriv(scrn);
> drmModeResPtr mode_res;
> - int i, j, s;
> + int i, j;
> Bool found;
> Bool changed = FALSE;
> int num_dvi = 0, num_hdmi = 0;
> @@ -2617,20 +2617,13 @@ restart_destroy:
>
> /* find new output ids we don't have outputs for */
> for (i = 0; i < mode_res->count_connectors; i++) {
> - found = FALSE;
> -
> - for (s = 0; !found && s < xf86NumScreens; s++) {
> - ScrnInfoPtr loop_scrn = xf86Screens[s];
> -
> - if (strcmp(loop_scrn->driverName, scrn-
> >driverName) ||
> - RADEONEntPriv(loop_scrn) != pRADEONEnt)
> - continue;
> -
> - found = drmmode_find_output(loop_scrn,
> - mode_res->connectors[i],
> - &num_dvi, &num_hdmi);
> - }
> - if (found)
> + if (drmmode_find_output(pRADEONEnt->primary_scrn,
> + mode_res->connectors[i],
> + &num_dvi, &num_hdmi) ||
> + (pRADEONEnt->secondary_scrn &&
> + drmmode_find_output(pRADEONEnt->secondary_scrn,
> + mode_res->connectors[i],
> + &num_dvi, &num_hdmi)))
> continue;
>
> if (drmmode_output_init(scrn, drmmode, mode_res, i,
> &num_dvi,
> diff --git a/src/radeon_kms.c b/src/radeon_kms.c
> index 6927f58..ee2becd 100644
> --- a/src/radeon_kms.c
> +++ b/src/radeon_kms.c
> @@ -1659,6 +1659,11 @@ Bool RADEONPreInit_KMS(ScrnInfoPtr pScrn, int
> flags)
> }
> }
>
> + if (info->IsSecondary)
> + pRADEONEnt->secondary_scrn = pScrn;
> + else
> + pRADEONEnt->primary_scrn = pScrn;
> +
> info->PciInfo = xf86GetPciInfoForEntity(info->pEnt->index);
> pScrn->monitor = pScrn->confScreen->monitor;
>
> diff --git a/src/radeon_probe.h b/src/radeon_probe.h
> index 258c7be..573d988 100644
> --- a/src/radeon_probe.h
> +++ b/src/radeon_probe.h
> @@ -139,6 +139,8 @@ typedef struct
> unsigned long fd_wakeup_registered; /* server generation for which fd
> has been registered for wakeup handling */
> int fd_wakeup_ref;
> unsigned int assigned_crtcs;
> + ScrnInfoPtr primary_scrn;
> + ScrnInfoPtr secondary_scrn;
> #ifdef XSERVER_PLATFORM_BUS
> struct xf86_platform_device *platform_dev;
> #endif
> --
> 2.10.2
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH] clk: gate: fix coding style
From: Uwe Kleine-König @ 2016-11-09 13:58 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Michael Turquette, Stephen Boyd, linux-clk, Jiri Kosina,
Sascha Hauer
In-Reply-To: <CAK7LNARSfBBFffOyRa03hGqfJ+7gSHe-A+Efm9oM1sOdgLL-Ag@mail.gmail.com>
Hello,
On Wed, Nov 09, 2016 at 08:25:22PM +0900, Masahiro Yamada wrote:
> 2016-11-09 20:00 GMT+09:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> > init.flags = flags | CLK_IS_BASIC;
> > - init.parent_names = (parent_name ? &parent_name: NULL);
> > + init.parent_names = (parent_name ? &parent_name : NULL);
> > init.num_parents = (parent_name ? 1 : 0);
>
> Do we need the parentheses?
init.num_parents = parent_name ? 1 : 0;
has the same semantics. I didn't remove the parentheses because they
might make it easier to understand what happens if you don't have the
operator precedence table at hand. But actually I don't care. If they
should be dropped and nobody else volunteers, I can resend with the
parentheses removed.
Best regards,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] sound: omap-twl4030: do not complain on -EPROBE_DEFER
From: Ladislav Michl @ 2016-11-09 13:58 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, linux-omap
Do not complain on -EPROBE_DEFER when initializing, the driver probe will
be retried later.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
sound/soc/omap/omap-twl4030.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-twl4030.c b/sound/soc/omap/omap-twl4030.c
index 7431314..c90882c 100644
--- a/sound/soc/omap/omap-twl4030.c
+++ b/sound/soc/omap/omap-twl4030.c
@@ -335,8 +335,10 @@ static int omap_twl4030_probe(struct platform_device *pdev)
snd_soc_card_set_drvdata(card, priv);
ret = devm_snd_soc_register_card(&pdev->dev, card);
if (ret) {
- dev_err(&pdev->dev, "devm_snd_soc_register_card() failed: %d\n",
- ret);
+ if (ret != -EPROBE_DEFER)
+ dev_err(&pdev->dev,
+ "devm_snd_soc_register_card() failed: %d\n",
+ ret);
return ret;
}
--
2.1.4
^ permalink raw reply related
* [PATCH] sequencer: shut up clang warning
From: Johannes Schindelin @ 2016-11-09 13:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Torsten Bögershausen, Lars Schneider,
Jeff King
[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]
When comparing a value of type `enum todo_command` with a value that is
outside the defined enum constants, clang greets the developer with this
warning:
comparison of constant 2 with expression of type
'const enum todo_command' is always true
While this is arguably true *iff* the value was never cast from a
free-form int, we should keep the cautious code in place.
To shut up clang, we simply introduce an otherwise pointless enum constant
and compare against that.
Noticed by Torsten Bögershausen.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Published-As: https://github.com/dscho/git/releases/tag/enum-warning-v1
Fetch-It-Via: git fetch https://github.com/dscho/git enum-warning-v1
Peff, if you would like me to include more of your commit message,
please let me know.
I will adjust the sequencer-i patches to keep the TODO_INVALID
constant.
sequencer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index 5fd75f3..f80e9c0 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -619,7 +619,8 @@ static int allow_empty(struct replay_opts *opts, struct commit *commit)
enum todo_command {
TODO_PICK = 0,
- TODO_REVERT
+ TODO_REVERT,
+ TODO_INVALID
};
static const char *todo_command_strings[] = {
@@ -629,7 +630,7 @@ static const char *todo_command_strings[] = {
static const char *command_to_string(const enum todo_command command)
{
- if (command < ARRAY_SIZE(todo_command_strings))
+ if (command < TODO_INVALID)
return todo_command_strings[command];
die("Unknown command: %d", command);
}
base-commit: be5a750939c212bc0781ffa04fabcfd2b2bd744e
--
2.10.1.583.g721a9e0
^ permalink raw reply related
* Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: One Thousand Gnomes @ 2016-11-09 13:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, zhichang.yuan, catalin.marinas, will.deacon,
robh+dt, bhelgaas, olof, linux-arm-kernel, lorenzo.pieralisi,
linux-kernel, linuxarm, devicetree, linux-pci, linux-serial,
minyard, benh, liviu.dudau, zourongrong, john.garry,
gabriele.paoloni, zhichang.yuan02, kantyzc, xuwei5, marc.zyngier
In-Reply-To: <2368890.jTbyGqYR0M@wuerfel>
> I think it is a relatively safe assumption that there is only one
> ISA bridge. A lot of old drivers hardcode PIO or memory addresses
It's not a safe assumption for x86 at least. There are a few systems with
multiple ISA busses particularly older laptops with a docking station.
> when talking to an ISA device, so having multiple instances is
> already problematic.
PCMCIA devices handle it themselves so are ok. I'm not clear how the dual
PIIX4 configuration used in the older IBM laptop docks actually worked so
I assume the transaction went out of both bridges and providing one of
them responded the other kept silent as you simply stuffed the card into
the dock and it worked.
Alan
^ permalink raw reply
* [Buildroot] [PATCH] qt5webkit: Get sources from Qt-5-unofficial-builds
From: Алексей Бродкин @ 2016-11-09 13:55 UTC (permalink / raw)
To: buildroot
In-Reply-To: <6163885.zDEeHnFoFK@sagittea>
Hi J?r?me,
2016-11-09 16:31 GMT+03:00 J?r?me Pouiller <jezz@sysmic.org>:
>
> Hello Alexey,
>
> On Wednesday 09 November 2016 15:38:05 Alexey Brodkin wrote:
> [...]
> > --- a/package/qt5/qt5.mk
> > +++ b/package/qt5/qt5.mk
> > @@ -1,6 +1,7 @@
> > QT5_VERSION_MAJOR = 5.6
> > QT5_VERSION = $(QT5_VERSION_MAJOR).2
> > QT5_SITE = http://download.qt.io/official_releases/qt/$(QT5_VERSION_MAJOR)/$(QT5_VERSION)/submodules
> > +QT5_SNAPSHOTS_SITE = http://download.qt.io/snapshots/qt/$(QT5_VERSION_MAJOR)/$(QT5_VERSION)/latest_src/submodules
>
> Is it possible to also use snapshots site for official modules?
I think it's possible, see
http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/submodules/
But I'd prefer to stick to official release paths for officially
supported submodules.
Just in case "snapshots" stuff gets purged at some point in time.
> [...]
> > --- a/package/qt5/qt5webkit/qt5webkit.mk
> > +++ b/package/qt5/qt5webkit/qt5webkit.mk
> > @@ -4,10 +4,9 @@
> > #
> > ################################################################################
> >
> > -QT5WEBKIT_VERSION = b35917bcb44d7f200af0f4ac68a126fa0aa8d93d
> > -# Using GitHub since it supports downloading tarballs from random commits.
> > -# The http://code.qt.io/cgit/qt/qtwebkit.git/ repo doesn't allow to do so.
> > -QT5WEBKIT_SITE = $(call github,qtproject,qtwebkit,$(QT5WEBKIT_VERSION))
> > +QT5WEBKIT_VERSION = $(QT5_VERSION)
> > +QT5WEBKIT_SITE = $(QT5_SNAPSHOTS_SITE)
> > +QT5WEBKIT_SOURCE = qtwebkit-opensource-src-$(QT5WEBKIT_EXAMPLES_VERSION).tar.xz
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> You mean QT5WEBKIT_VERSION?
Did I send it? Oh boy... I was daydreaming most probably.
That's how people and companies leak their secrets :)
I was trying to bring WebkitExamples back in BR and this one was a prerequisite
that simplifies recovery of WebkitExamples sources. That said the
patch was build-tested
but with another patch on top of it and so I didn't catch this copy-pasta.
Will do a respin now.
-Alexey
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.