* Re: [linux-sunxi] [PATCH v7 5/6] drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
From: Jernej Škrabec @ 2019-06-20 15:47 UTC (permalink / raw)
To: linux-sunxi, megous
Cc: Mark Rutland, Jose Abreu, Alexandre Torgue, devicetree,
Maxime Ripard, netdev, linux-kernel, dri-devel, linux-stm32,
David Airlie, Chen-Yu Tsai, Rob Herring, linux-arm-kernel,
Daniel Vetter, Giuseppe Cavallaro, David S. Miller,
Maxime Coquelin
In-Reply-To: <20190620134748.17866-6-megous@megous.com>
Dne četrtek, 20. junij 2019 ob 15:47:47 CEST je megous via linux-sunxi
napisal(a):
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
> for the DDC bus to be usable.
>
> Add support for hdmi-connector node's optional ddc-en-gpios property to
> support this use case.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Best regards,
Jernej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v7 5/6] drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
From: Jernej Škrabec @ 2019-06-20 15:47 UTC (permalink / raw)
To: linux-sunxi, megous
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie,
Daniel Vetter, Mark Rutland, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32
In-Reply-To: <20190620134748.17866-6-megous@megous.com>
Dne četrtek, 20. junij 2019 ob 15:47:47 CEST je megous via linux-sunxi
napisal(a):
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
> for the DDC bus to be usable.
>
> Add support for hdmi-connector node's optional ddc-en-gpios property to
> support this use case.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Best regards,
Jernej
^ permalink raw reply
* [PATCH] bash: Remove .build files for reproducible builds
From: Joshua Watt @ 2019-06-20 15:47 UTC (permalink / raw)
To: openembedded-core
Bash has an internal "build number" that it tracks and automatically
increments ever time a given builds is made from the same sandbox.
However, this can make builds non-reproducible in the event that a build
directory is reused multiple times.
Remove the .build files after every build if reproducible builds have
been requested which will reset the build build number for the next
build.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
meta/recipes-extended/bash/bash.inc | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/meta/recipes-extended/bash/bash.inc b/meta/recipes-extended/bash/bash.inc
index c91cc8ada8d..e2844dffbad 100644
--- a/meta/recipes-extended/bash/bash.inc
+++ b/meta/recipes-extended/bash/bash.inc
@@ -39,6 +39,14 @@ RDEPENDS_${PN}-ptest_append_libc-glibc = " \
CACHED_CONFIGUREVARS += "headersdir=${includedir}/${PN}"
+do_compile_prepend() {
+ # If reproducible builds are requested, remove any leftover .build files.
+ # This ensures that bash always has the same version number
+ if [ "${BUILD_REPRODUCIBLE_BINARIES}" == "1" ]; then
+ rm -f ${B}/.build
+ fi
+}
+
do_compile_ptest () {
oe_runmake buildtest
}
--
2.21.0
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v2 01/20] hw/i386/pc: Use unsigned type to index arrays
From: Michael S. Tsirkin @ 2019-06-20 15:27 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Yang Zhong, Eduardo Habkost, kvm, Marcelo Tosatti, Li Qiang,
qemu-devel, Rob Bradford, Paolo Bonzini, Samuel Ortiz,
Richard Henderson
In-Reply-To: <20190613143446.23937-2-philmd@redhat.com>
On Thu, Jun 13, 2019 at 04:34:27PM +0200, Philippe Mathieu-Daudé wrote:
> Reviewed-by: Li Qiang <liq3ea@gmail.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Motivation? Is this a bugfix?
> ---
> hw/i386/pc.c | 5 +++--
> include/hw/i386/pc.h | 2 +-
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 2c5446b095..bb3c74f4ca 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -874,7 +874,7 @@ static void handle_a20_line_change(void *opaque, int irq, int level)
>
> int e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
> {
> - int index = le32_to_cpu(e820_reserve.count);
> + unsigned int index = le32_to_cpu(e820_reserve.count);
> struct e820_entry *entry;
>
> if (type != E820_RAM) {
> @@ -906,7 +906,8 @@ int e820_get_num_entries(void)
> return e820_entries;
> }
>
> -bool e820_get_entry(int idx, uint32_t type, uint64_t *address, uint64_t *length)
> +bool e820_get_entry(unsigned int idx, uint32_t type,
> + uint64_t *address, uint64_t *length)
> {
> if (idx < e820_entries && e820_table[idx].type == cpu_to_le32(type)) {
> *address = le64_to_cpu(e820_table[idx].address);
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index a7d0b87166..3b3a0d6e59 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -291,7 +291,7 @@ void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
>
> int e820_add_entry(uint64_t, uint64_t, uint32_t);
> int e820_get_num_entries(void);
> -bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
> +bool e820_get_entry(unsigned int, uint32_t, uint64_t *, uint64_t *);
>
> extern GlobalProperty pc_compat_4_0_1[];
> extern const size_t pc_compat_4_0_1_len;
> --
> 2.20.1
^ permalink raw reply
* Re: [PATCH] kbuild: Enable -Wuninitialized
From: Masahiro Yamada @ 2019-06-20 15:45 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Michal Marek, Linux Kbuild mailing list,
Linux Kernel Mailing List, Nick Desaulniers, Arnd Bergmann,
clang-built-linux
In-Reply-To: <20190614165242.79257-1-natechancellor@gmail.com>
On Sat, Jun 15, 2019 at 1:53 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> This helps fine very dodgy behavior through both -Wuninitialized
> (warning that a variable is always uninitialized) and
> -Wsometimes-uninitialized (warning that a variable is sometimes
> uninitialized, like GCC's -Wmaybe-uninitialized). These warnings
> catch things that GCC doesn't such as:
>
> https://lore.kernel.org/lkml/86649ee4-9794-77a3-502c-f4cd10019c36@lca.pw/
>
> We very much want to catch these so turn this warning on so that CI is
> aware of it.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/381
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
Applied to linux-kbuild.
Thanks!
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH] drm: Dump mode picture aspect ratio
From: Ville Syrjala @ 2019-06-20 15:46 UTC (permalink / raw)
To: dri-devel; +Cc: intel-gfx, Ilia Mirkin
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Currently the logs show nothing about the mode's aspect ratio.
Include that information in the normal mode dump.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/video/hdmi.c | 3 ++-
include/drm/drm_modes.h | 4 ++--
include/linux/hdmi.h | 3 +++
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index b939bc28d886..bc593fe1c268 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1057,7 +1057,7 @@ static const char *hdmi_colorimetry_get_name(enum hdmi_colorimetry colorimetry)
return "Invalid";
}
-static const char *
+const char *
hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect)
{
switch (picture_aspect) {
@@ -1076,6 +1076,7 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect)
}
return "Invalid";
}
+EXPORT_SYMBOL(hdmi_picture_aspect_get_name);
static const char *
hdmi_active_aspect_get_name(enum hdmi_active_aspect active_aspect)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 083f16747369..2b1809c74fbe 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -431,7 +431,7 @@ struct drm_display_mode {
/**
* DRM_MODE_FMT - printf string for &struct drm_display_mode
*/
-#define DRM_MODE_FMT "\"%s\": %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x"
+#define DRM_MODE_FMT "\"%s\": %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x %s"
/**
* DRM_MODE_ARG - printf arguments for &struct drm_display_mode
@@ -441,7 +441,7 @@ struct drm_display_mode {
(m)->name, (m)->vrefresh, (m)->clock, \
(m)->hdisplay, (m)->hsync_start, (m)->hsync_end, (m)->htotal, \
(m)->vdisplay, (m)->vsync_start, (m)->vsync_end, (m)->vtotal, \
- (m)->type, (m)->flags
+ (m)->type, (m)->flags, hdmi_picture_aspect_get_name((m)->picture_aspect_ratio)
#define obj_to_mode(x) container_of(x, struct drm_display_mode, base)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 9918a6c910c5..de7cbe385dba 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -434,4 +434,7 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
void hdmi_infoframe_log(const char *level, struct device *dev,
const union hdmi_infoframe *frame);
+const char *
+hdmi_picture_aspect_get_name(enum hdmi_picture_aspect picture_aspect);
+
#endif /* _DRM_HDMI_H */
--
2.21.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v2 04/20] hw/i386/pc: Add the E820Type enum type
From: Michael S. Tsirkin @ 2019-06-20 15:31 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Yang Zhong, Eduardo Habkost, kvm, Marcelo Tosatti, qemu-devel,
Rob Bradford, Paolo Bonzini, Samuel Ortiz, Richard Henderson
In-Reply-To: <20190613143446.23937-5-philmd@redhat.com>
On Thu, Jun 13, 2019 at 04:34:30PM +0200, Philippe Mathieu-Daudé wrote:
> This ensure we won't use an incorrect value.
>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
It doesn't actually ensure anything: compiler does not check IIUC.
And OTOH it's stored in type field in struct e820_entry.
> ---
> v2: Do not cast the enum (Li)
> ---
> hw/i386/pc.c | 4 ++--
> include/hw/i386/pc.h | 16 ++++++++++------
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 5a7cffbb1a..86ba554439 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -872,7 +872,7 @@ static void handle_a20_line_change(void *opaque, int irq, int level)
> x86_cpu_set_a20(cpu, level);
> }
>
> -ssize_t e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
> +ssize_t e820_add_entry(uint64_t address, uint64_t length, E820Type type)
> {
> unsigned int index = le32_to_cpu(e820_reserve.count);
> struct e820_entry *entry;
> @@ -906,7 +906,7 @@ size_t e820_get_num_entries(void)
> return e820_entries;
> }
>
> -bool e820_get_entry(unsigned int idx, uint32_t type,
> +bool e820_get_entry(unsigned int idx, E820Type type,
> uint64_t *address, uint64_t *length)
> {
> if (idx < e820_entries && e820_table[idx].type == cpu_to_le32(type)) {
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index c56116e6f6..7c07185dd5 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -282,12 +282,16 @@ void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory);
> void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
> const CPUArchIdList *apic_ids, GArray *entry);
>
> -/* e820 types */
> -#define E820_RAM 1
> -#define E820_RESERVED 2
> -#define E820_ACPI 3
> -#define E820_NVS 4
> -#define E820_UNUSABLE 5
> +/**
> + * E820Type: Type of the e820 address range.
> + */
> +typedef enum {
> + E820_RAM = 1,
> + E820_RESERVED = 2,
> + E820_ACPI = 3,
> + E820_NVS = 4,
> + E820_UNUSABLE = 5
> +} E820Type;
>
> ssize_t e820_add_entry(uint64_t, uint64_t, uint32_t);
> size_t e820_get_num_entries(void);
> --
> 2.20.1
^ permalink raw reply
* Re: [usb:usb-testing 46/46] drivers/usb//misc/adutux.c:375:4: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}'
From: Alan Stern @ 2019-06-20 15:45 UTC (permalink / raw)
To: dmg; +Cc: linux-usb, Greg Kroah-Hartman
In-Reply-To: <87wohgs3lh.fsf@mn.cs.uvic.ca>
On Thu, 20 Jun 2019, dmg wrote:
>
> kbuild test robot <lkp@intel.com> writes:
>
> [...]
> >
> > All warnings (new ones prefixed by >>):
> >
> > In file included from include/linux/printk.h:332:0,
> > from include/linux/kernel.h:15,
> > from drivers/usb//misc/adutux.c:19:
> > drivers/usb//misc/adutux.c: In function 'adu_read':
> >>> drivers/usb//misc/adutux.c:375:4: warning: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t {aka unsigned int}' [-Wformat=]
> > "%s : while, data_in_secondary=%lu, status=%d\n",
>
> I am not sure what is the best way to address this warning.
>
> size_t seems to be architecture dependent. On my computer (intel64)
> size_t is long unsigned int, but in this test it is int unsigned.
>
> Are there any suggestions on what is the best way to deal with this?
Use the %zu format specifier instead of %lu. This is explained in
Documentation/core-api/printk-formats.rst.
Alan Stern
> casting size_t to long unsigned int will work, but it sounds kind of
> ugly.
>
>
> thank you,
>
>
> --daniel
>
>
> --
> Daniel M. German "We die. That may be the meaning of life.
> But we do language. That may be
> Toni Morrison -> the measure of our lives."
> http://turingmachine.org/
> http://silvernegative.com/
> dmg (at) uvic (dot) ca
> replace (at) with @ and (dot) with .
>
>
^ permalink raw reply
* Re: Move away from default password
From: Joseph Reynolds @ 2019-06-20 15:46 UTC (permalink / raw)
To: Stewart Smith; +Cc: Openbmc, openbmc
In-Reply-To: <874l4n6ct4.fsf@linux.vnet.ibm.com>
On 2019-06-17 17:56, Stewart Smith wrote:
> Joseph Reynolds <jrey@linux.ibm.com> writes:
>> There is some interest in moving OpenBMC away from a default password.
>> - email:
>> https://lists.ozlabs.org/pipermail/openbmc/2019-June/016515.html
>> (which
>> references a RestrictionMode design:
>> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/21195)
>>
>> Having a default password is a security risk. Note that changing to a
>> different default password is not a good solution. For example, if a
>> bad actor learns the default password from one device, that actor will
>> likely know the password for many of them.
>
> and it makes it pretty easy to use something like Shodan to find all
> the
> possible OpenBMCs connected to the Internet (hopefully by accident) and
> pop a root shell on them.
>
> Mind you, in a lab environment, it's *really* useful.
I imagine for the forseeable future, OpenBMC would continue to have a
default userid and password (and I hope each development lab is using a
different default password than the well-known password). But I think
development labs are subject to attack, so we need to eventually move
away from default passwords even in the development labs.
At this time, I am looking for options to move away from this model, but
do not anticipate changing the default.
>> I am exploring two options for OpenBMC, and want your feedback.
>>
>> 1. Unique password per BMC.
>> In this approach, there is a way to change the factory default
>> password.
>> Example flow: assemble the BMC, test it, factory reset, generate
>> unique
>> password (such as `pwgen`), then use a new function “save factory
>> default settings” which would save the current setting into a new
>> “factory settings” flash partition. After that, a factory reset
>> would reset to the factory installed password, not to the setting in
>> the
>> source code.
>> Presumably the new factory default would be printed on a sticker, or
>> something.
>> Are there any other factory settings (settings unique to each device)
>> that would benefit from being set like this?
>> One downside to this approach is someone who orders 100 systems has to
>> enter 100 unique passwords.
>
> There's also a downside for those of us who often work remotely from
> machines, we may have to wait for someone to be awake and be able to
> physically go and check what the default password is.
>
>> 2. Create new account on first access.
>> Specifically, default OpenBMC to use a new RestrictionMode=SetupAccess
>> which:
>> - (A) requires users to set up their credentials (at least: remove
>> the
>> default password) before they can leave that mode, and
>> - (B) does not let the user do anything else, including other
>> provisioning or operating the host, while in this mode.
>> So we could manufacture the BMC with a default password, but require
>> it
>> to be changed as the first step to provision the BMC.
>> We might want to make network services react to this new mode, for
>> example, the phosphor-webui GUI would likely want to handle this
>> specially, and most REST APIs would be restricted.
>> Note this approach gives an attacker a window of time before the
>> credentials are set up.
>
> In a lab environment though, we'd have to ensure we had a *very*
> reliably way to reset the BMC when we switched who was using the
> machine.
Agreed. Gaining initial access and recovering access the BMC is one of
the issues.
>> I believe both of these approaches represent reasonable security
>> practices which may satisfy laws regarding consumer products. For
>> example, CA Law SB-327
>> https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180SB327
>>
>> Are there guidelines we can follow? Can you find additional
>> vulnerabilities with these approaches? Can we do better than this
>> without requiring additional infrastructure?
>>
>> I plan to discuss this at the 2019-06-26 Security working group
>> meeting:
>> https://docs.google.com/document/d/1b7x9BaxsfcukQDqbvZsU2ehMq4xoJRQvLxxsDUWmAOI/
>> and would be happy to see ideas here.
>
> I had an idea that provides less security, but still may be valuable:
> make the default password at manufacturing be linked to the MAC address
> of the BMC. This prevents people not on a local network to the machine
> from gaining access (e.g. I have no idea what the MAC address of
> 8.8.8.8
> is), but if I'm on the same ethernet network, then I can still work it
> out. It would also allow someone buying 100 machines to programatically
> work out what the password should be.
Thanks, I understand this idea. It may satisfy the letter of the law,
and perhaps also its intent (disclaimer: not a legal opinion), so it has
some merit. But this scheme not as secure as random passwords
(specifically, if the attacker learns the MAC addresses).
- Joseph
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v17 02/10] ACPI: add some GHES structures and macros definition
From: Igor Mammedov @ 2019-06-20 15:09 UTC (permalink / raw)
To: gengdongjiu
Cc: peter.maydell, ehabkost, kvm, mst, mtosatti, qemu-devel, linuxarm,
shannon.zhaosl, zhengxiang9, qemu-arm, james.morse, xuwei5,
jonathan.cameron, pbonzini, lersek, rth
In-Reply-To: <f4f94ecb-200c-3e18-1a09-5fb6bc761834@huawei.com>
On Thu, 20 Jun 2019 22:04:01 +0800
gengdongjiu <gengdongjiu@huawei.com> wrote:
> Hi Igor,
> Thanks for your review.
>
> On 2019/6/20 20:10, Igor Mammedov wrote:
> >> + */
> >> +struct AcpiGenericErrorStatus {
> >> + /* It is a bitmask composed of ACPI_GEBS_xxx macros */
> >> + uint32_t block_status;
> >> + uint32_t raw_data_offset;
> >> + uint32_t raw_data_length;
> >> + uint32_t data_length;
> >> + uint32_t error_severity;
> >> +} QEMU_PACKED;
> >> +typedef struct AcpiGenericErrorStatus AcpiGenericErrorStatus;
> > there shouldn't be packed structures,
> > is it a leftover from previous version?
>
> I remember some people suggest to add QEMU_PACKED before, anyway I will remove it in my next version patch.
Question is why it's there and where it is used?
BTW:
series doesn't apply to master anymore.
Do you have a repo somewhere available for testing?
>
> >
> >> +
> >> +/*
> >> + * Masks for block_status flags above
> >> + */
> >> +#define ACPI_GEBS_UNCORRECTABLE 1
> >> +
> >> +/*
>
^ permalink raw reply
* [PATCH 2/2] python3: Disable PGO for reproducible builds
From: Joshua Watt @ 2019-06-20 15:43 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <20190620154302.9251-1-JPEWhacker@gmail.com>
Enabling PGO for python current causes it to not be reproducible when
building, so disable it for now.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
meta/recipes-devtools/python/python3_3.7.3.bb | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3_3.7.3.bb b/meta/recipes-devtools/python/python3_3.7.3.bb
index d14c93880fb..40e2229a165 100644
--- a/meta/recipes-devtools/python/python3_3.7.3.bb
+++ b/meta/recipes-devtools/python/python3_3.7.3.bb
@@ -79,8 +79,16 @@ CACHED_CONFIGUREVARS = " \
ac_cv_file__dev_ptc=no \
ac_cv_working_tzset=yes \
"
+python() {
+ # PGO currently causes builds to not be reproducible, so disable it for
+ # now. See YOCTO #13407
+ if bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', True, False, d) and d.getVar('BUILD_REPRODUCIBLE_BINARIES') != '1':
+ d.setVar('PACKAGECONFIG_PGO', 'pgo')
+ else:
+ d.setVar('PACKAGECONFIG_PGO', '')
+}
-PACKAGECONFIG_class-target ??= "readline ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 'pgo', '', d)}"
+PACKAGECONFIG_class-target ??= "readline ${PACKAGECONFIG_PGO}"
PACKAGECONFIG_class-native ??= "readline"
PACKAGECONFIG_class-nativesdk ??= "readline"
PACKAGECONFIG[readline] = ",,readline"
--
2.21.0
^ permalink raw reply related
* [PATCH 1/2] python3: Reformat sysconfig
From: Joshua Watt @ 2019-06-20 15:43 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <20190620154302.9251-1-JPEWhacker@gmail.com>
Reformats the sysconfig file when packaging. This file is output by
using the python pprint function. This function will wrap long lines at
80 characters by default, and will even split strings at whitespace
boundaries to do so, e.g.:
'A': 'B is really'
' long'
This causes a problem for reproducibility however because there might be
lines of differing lengths depending on the build path. These
non-reproducible paths are removed, but their effect on string wrapping
from pprint remains.
To correct this, reformat the entire sysconfig file by re-printing using
pprint with an (effectively) unlimited line length.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
.../python/python3/reformat_sysconfig.py | 21 +++++++++++++++++++
meta/recipes-devtools/python/python3_3.7.3.bb | 10 +++++++++
2 files changed, 31 insertions(+)
create mode 100644 meta/recipes-devtools/python/python3/reformat_sysconfig.py
diff --git a/meta/recipes-devtools/python/python3/reformat_sysconfig.py b/meta/recipes-devtools/python/python3/reformat_sysconfig.py
new file mode 100644
index 00000000000..c4164313e8b
--- /dev/null
+++ b/meta/recipes-devtools/python/python3/reformat_sysconfig.py
@@ -0,0 +1,21 @@
+#! /usr/bin/env python3
+#
+# SPDX-License-Identifier: MIT
+#
+# Copyright 2019 by Garmin Ltd. or its subsidiaries
+#
+# A script to reformat python sysconfig
+
+import sys
+import pprint
+l = {}
+g = {}
+with open(sys.argv[1], 'r') as f:
+ exec(f.read(), g, l)
+
+with open(sys.argv[1], 'w') as f:
+ for k in sorted(l.keys()):
+ f.write('%s = ' % k)
+ pprint.pprint(l[k], stream=f, width=sys.maxsize)
+ f.write('\n')
+
diff --git a/meta/recipes-devtools/python/python3_3.7.3.bb b/meta/recipes-devtools/python/python3_3.7.3.bb
index 24442961421..d14c93880fb 100644
--- a/meta/recipes-devtools/python/python3_3.7.3.bb
+++ b/meta/recipes-devtools/python/python3_3.7.3.bb
@@ -27,6 +27,10 @@ SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \
file://crosspythonpath.patch \
"
+SRC_URI_append_class-target = " \
+ file://reformat_sysconfig.py \
+ "
+
SRC_URI_append_class-native = " \
file://0001-distutils-sysconfig-append-STAGING_LIBDIR-python-sys.patch \
file://12-distutils-prefix-is-inside-staging-area.patch \
@@ -157,6 +161,12 @@ py_package_preprocess () {
${PKGD}/${libdir}/python${PYTHON_MAJMIN}/_sysconfigdata*.py \
${PKGD}/${bindir}/python${PYTHON_BINABI}-config
+ # Reformat _sysconfigdata after modifying it so that it remains
+ # reproducible
+ for c in ${PKGD}/${libdir}/python${PYTHON_MAJMIN}/_sysconfigdata*.py; do
+ python3 ${WORKDIR}/reformat_sysconfig.py $c
+ done
+
# Recompile _sysconfigdata after modifying it
cd ${PKGD}
sysconfigfile=`find . -name _sysconfigdata_*.py`
--
2.21.0
^ permalink raw reply related
* [PATCH 0/2] python3: Reproducible build fixes
From: Joshua Watt @ 2019-06-20 15:43 UTC (permalink / raw)
To: openembedded-core
Two fixes to make the Python3 build reproducible
Joshua Watt (2):
python3: Reformat sysconfig
python3: Disable PGO for reproducible builds
.../python/python3/reformat_sysconfig.py | 21 +++++++++++++++++++
meta/recipes-devtools/python/python3_3.7.3.bb | 20 +++++++++++++++++-
2 files changed, 40 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-devtools/python/python3/reformat_sysconfig.py
--
2.21.0
^ permalink raw reply
* Re: [PATCH] drm/i915: Implement read-only support in whitelist selftest
From: Tvrtko Ursulin @ 2019-06-20 15:43 UTC (permalink / raw)
To: John.C.Harrison, Intel-GFX
In-Reply-To: <20190618195421.31027-1-John.C.Harrison@Intel.com>
Hi,
You will need to send this not as reply to this thread so it is picked
up by CI and then can be merged.
But please also add a patch which adds that GEM_BUG_ON reg->flags check
we talked about.
Regards,
Tvrtko
On 18/06/2019 20:54, John.C.Harrison@Intel.com wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> Newer hardware supports extra feature in the whitelist registers. This
> patch updates the selftest to test that entries marked as read only
> are actually read only.
>
> Also updated the read/write access definitions to make it clearer that
> they are an enum field not a set of single bit flags.
>
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> CC: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +--
> .../gpu/drm/i915/gt/selftest_workarounds.c | 53 +++++++++++++------
> drivers/gpu/drm/i915/i915_reg.h | 9 ++--
> 3 files changed, 48 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 93caa7b6d7a9..4429ee08b20e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1028,7 +1028,7 @@ whitelist_reg_ext(struct i915_wa_list *wal, i915_reg_t reg, u32 flags)
> static void
> whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
> {
> - whitelist_reg_ext(wal, reg, RING_FORCE_TO_NONPRIV_RW);
> + whitelist_reg_ext(wal, reg, RING_FORCE_TO_NONPRIV_ACCESS_RW);
> }
>
> static void gen9_whitelist_build(struct i915_wa_list *w)
> @@ -1134,13 +1134,13 @@ printk(KERN_INFO "%-32s:%4d> Boo! [engine = %s, instance = %d, base = 0x%X, reg
>
> /* hucStatusRegOffset */
> whitelist_reg_ext(w, _MMIO(0x2000 + engine->mmio_base),
> - RING_FORCE_TO_NONPRIV_RD);
> + RING_FORCE_TO_NONPRIV_ACCESS_RD);
> /* hucUKernelHdrInfoRegOffset */
> whitelist_reg_ext(w, _MMIO(0x2014 + engine->mmio_base),
> - RING_FORCE_TO_NONPRIV_RD);
> + RING_FORCE_TO_NONPRIV_ACCESS_RD);
> /* hucStatus2RegOffset */
> whitelist_reg_ext(w, _MMIO(0x23B0 + engine->mmio_base),
> - RING_FORCE_TO_NONPRIV_RD);
> + RING_FORCE_TO_NONPRIV_ACCESS_RD);
> break;
>
> default:
> diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> index eb6d3aa2c8cc..a0a88ec66861 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
> @@ -399,6 +399,10 @@ static bool wo_register(struct intel_engine_cs *engine, u32 reg)
> enum intel_platform platform = INTEL_INFO(engine->i915)->platform;
> int i;
>
> + if ((reg & RING_FORCE_TO_NONPRIV_ACCESS_MASK) ==
> + RING_FORCE_TO_NONPRIV_ACCESS_WR)
> + return true;
> +
> for (i = 0; i < ARRAY_SIZE(wo_registers); i++) {
> if (wo_registers[i].platform == platform &&
> wo_registers[i].reg == reg)
> @@ -410,7 +414,8 @@ static bool wo_register(struct intel_engine_cs *engine, u32 reg)
>
> static bool ro_register(u32 reg)
> {
> - if (reg & RING_FORCE_TO_NONPRIV_RD)
> + if ((reg & RING_FORCE_TO_NONPRIV_ACCESS_MASK) ==
> + RING_FORCE_TO_NONPRIV_ACCESS_RD)
> return true;
>
> return false;
> @@ -482,12 +487,12 @@ static int check_dirty_whitelist(struct i915_gem_context *ctx,
> u32 srm, lrm, rsvd;
> u32 expect;
> int idx;
> + bool ro_reg;
>
> if (wo_register(engine, reg))
> continue;
>
> - if (ro_register(reg))
> - continue;
> + ro_reg = ro_register(reg);
>
> srm = MI_STORE_REGISTER_MEM;
> lrm = MI_LOAD_REGISTER_MEM;
> @@ -588,24 +593,36 @@ static int check_dirty_whitelist(struct i915_gem_context *ctx,
> }
>
> GEM_BUG_ON(values[ARRAY_SIZE(values) - 1] != 0xffffffff);
> - rsvd = results[ARRAY_SIZE(values)]; /* detect write masking */
> - if (!rsvd) {
> - pr_err("%s: Unable to write to whitelisted register %x\n",
> - engine->name, reg);
> - err = -EINVAL;
> - goto out_unpin;
> + if (ro_reg) {
> + rsvd = 0xFFFFFFFF;
> + } else {
> + rsvd = results[ARRAY_SIZE(values)]; /* detect write masking */
> + if (!rsvd) {
> + pr_err("%s: Unable to write to whitelisted register %x\n",
> + engine->name, reg);
> + err = -EINVAL;
> + goto out_unpin;
> + }
> }
>
> expect = results[0];
> idx = 1;
> for (v = 0; v < ARRAY_SIZE(values); v++) {
> - expect = reg_write(expect, values[v], rsvd);
> + if (ro_reg)
> + expect = results[0];
> + else
> + expect = reg_write(expect, values[v], rsvd);
> +
> if (results[idx] != expect)
> err++;
> idx++;
> }
> for (v = 0; v < ARRAY_SIZE(values); v++) {
> - expect = reg_write(expect, ~values[v], rsvd);
> + if (ro_reg)
> + expect = results[0];
> + else
> + expect = reg_write(expect, ~values[v], rsvd);
> +
> if (results[idx] != expect)
> err++;
> idx++;
> @@ -622,7 +639,10 @@ static int check_dirty_whitelist(struct i915_gem_context *ctx,
> for (v = 0; v < ARRAY_SIZE(values); v++) {
> u32 w = values[v];
>
> - expect = reg_write(expect, w, rsvd);
> + if (ro_reg)
> + expect = results[0];
> + else
> + expect = reg_write(expect, w, rsvd);
> pr_info("Wrote %08x, read %08x, expect %08x\n",
> w, results[idx], expect);
> idx++;
> @@ -630,7 +650,10 @@ static int check_dirty_whitelist(struct i915_gem_context *ctx,
> for (v = 0; v < ARRAY_SIZE(values); v++) {
> u32 w = ~values[v];
>
> - expect = reg_write(expect, w, rsvd);
> + if (ro_reg)
> + expect = results[0];
> + else
> + expect = reg_write(expect, w, rsvd);
> pr_info("Wrote %08x, read %08x, expect %08x\n",
> w, results[idx], expect);
> idx++;
> @@ -762,8 +785,8 @@ static int read_whitelisted_registers(struct i915_gem_context *ctx,
> u64 offset = results->node.start + sizeof(u32) * i;
> u32 reg = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
>
> - /* Clear RD only and WR only flags */
> - reg &= ~(RING_FORCE_TO_NONPRIV_RD | RING_FORCE_TO_NONPRIV_WR);
> + /* Clear access permission field */
> + reg &= ~RING_FORCE_TO_NONPRIV_ACCESS_MASK;
>
> *cs++ = srm;
> *cs++ = reg;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index cc295a4f6e92..ba22e3b8f77e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2513,13 +2513,16 @@ enum i915_power_well_id {
> #define RING_WAIT_SEMAPHORE (1 << 10) /* gen6+ */
>
> #define RING_FORCE_TO_NONPRIV(base, i) _MMIO(((base) + 0x4D0) + (i) * 4)
> -#define RING_FORCE_TO_NONPRIV_RW (0 << 28) /* CFL+ & Gen11+ */
> -#define RING_FORCE_TO_NONPRIV_RD (1 << 28)
> -#define RING_FORCE_TO_NONPRIV_WR (2 << 28)
> +#define RING_FORCE_TO_NONPRIV_ACCESS_RW (0 << 28) /* CFL+ & Gen11+ */
> +#define RING_FORCE_TO_NONPRIV_ACCESS_RD (1 << 28)
> +#define RING_FORCE_TO_NONPRIV_ACCESS_WR (2 << 28)
> +#define RING_FORCE_TO_NONPRIV_ACCESS_INVALID (3 << 28)
> +#define RING_FORCE_TO_NONPRIV_ACCESS_MASK (3 << 28)
> #define RING_FORCE_TO_NONPRIV_RANGE_1 (0 << 0) /* CFL+ & Gen11+ */
> #define RING_FORCE_TO_NONPRIV_RANGE_4 (1 << 0)
> #define RING_FORCE_TO_NONPRIV_RANGE_16 (2 << 0)
> #define RING_FORCE_TO_NONPRIV_RANGE_64 (3 << 0)
> +#define RING_FORCE_TO_NONPRIV_RANGE_MASK (3 << 0)
> #define RING_MAX_NONPRIV_SLOTS 12
>
> #define GEN7_TLB_RD_ADDR _MMIO(0x4700)
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 3/3] crypto: inside-secure - add support for using the EIP197 without firmware images
From: Antoine Tenart @ 2019-06-20 15:42 UTC (permalink / raw)
To: Pascal Van Leeuwen
Cc: Antoine Tenart, Pascal van Leeuwen, linux-crypto@vger.kernel.org,
herbert@gondor.apana.org.au, davem@davemloft.net
In-Reply-To: <AM6PR09MB35236CA6971A1B6D03AB9BD4D2E40@AM6PR09MB3523.eurprd09.prod.outlook.com>
Hi Pascal,
On Thu, Jun 20, 2019 at 02:59:20PM +0000, Pascal Van Leeuwen wrote:
> > From: Antoine Tenart <antoine.tenart@bootlin.com>
> > On Wed, Jun 19, 2019 at 02:37:44PM +0000, Pascal Van Leeuwen wrote:
> > > > From: Antoine Tenart <antoine.tenart@bootlin.com>
> > > > On Tue, Jun 18, 2019 at 07:56:24AM +0200, Pascal van Leeuwen wrote:
> > >
> > > > In addition to this, the direction the kernel has taken was to *remove*
> > > > binary firmwares from its source code. I'm afraid adding this is a
> > > > no-go.
> > >
> > > For a HW engineer, there really is no fundamental difference between
> > > control register contents or an instruction word. They can both have
> > > the exact same effects internal to the HW.
> > > If I had disguised this as a handful of config reg writes writing
> > > some #define'd magic values, probably no one would have even noticed.
> >
> > I do not fully agree. If this is comparable to configuring h/w
> > registers, then you could probably have defines explaining why each bit
> > is set and what it's doing. Which would be fine.
> >
> Strictly speaking, we (and probably most other HW vendors as well) don't do
> that for every register bit either, not even in the official Programmer Manual.
> Some bits are just "you don't need to know, just write this" :-)
That's right... :-(
> > > By that same definition, the tokens the driver generates for
> > > processing could be considered "firmware" as well (as they are used by
> > > the hardware in a very similar way) ...
> >
> > Right. The main difference here is we do have a clear definition of what
> > the tokens are doing. Thanks to your explanation, if this firmware is
> > really looking like the token we're using, the words have a defined
> > structure and the magic values could be generated with proper defines
> > and macros. And I think it's the main issue here: it's not acceptable to
> > have an array of magic values. If you can give a meaning to those bits,
> > I see no reason why it couldn't be added to the driver.
> >
> > (And I'm all for what you're trying to achieve here :)).
> >
> Now we're reaching a tricky subject. Because I think if some people here
> find out those token bits are explicitly documented in the driver, they
> will not be so happy ... (don't worry, I won't wake any sleeping dogs :-)
> We provide this information to our customers under NDA, but it's
> obviously quite sensitive information as it reveals a lot about the
> inner workings of our HW design.
>
> The encoding of the microengine control words is considered even
> more sensitive, so we don't even provide that under NDA.
> Adding that to the driver will probably get me in trouble.
I fully understand this. This is not perfect, but at least it's the way
it is right now.
> So maybe putting these images in /lib/firmware is unavoidable, but
> I'd really like to hear some more opinions on that subject.
Yes, you either have to choice to put it in /lib/firmware (and in the
linux-firmwares project!) or to convince people to allow releasing this.
We can wait for others to hop in on the discussion, of course.
Thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net] ipv6: fix neighbour resolution with raw socket
From: Nicolas Dichtel @ 2019-06-20 15:42 UTC (permalink / raw)
To: David Ahern, davem; +Cc: netdev
In-Reply-To: <fb3ed305-0161-8d6a-975c-54b29cfcb0ef@gmail.com>
Le 20/06/2019 à 17:12, David Ahern a écrit :
> On 6/20/19 6:34 AM, Nicolas Dichtel wrote:
>> The scenario is the following: the user uses a raw socket to send an ipv6
>> packet, destinated to a not-connected network, and specify a connected nh.
>> Here is the corresponding python script to reproduce this scenario:
>>
>> import socket
>> IPPROTO_RAW = 255
>> send_s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, IPPROTO_RAW)
>> # scapy
>> # p = IPv6(src='fd00:100::1', dst='fd00:200::fa')/ICMPv6EchoRequest()
>> # str(p)
>> req = b'`\x00\x00\x00\x00\x08:@\xfd\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xfd\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfa\x80\x00\x81\xc0\x00\x00\x00\x00'
>> send_s.sendto(req, ('fd00:175::2', 0, 0, 0))
>>
>> fd00:175::/64 is a connected route and fd00:200::fa is not a connected
>> host.
>>
>> With this scenario, the kernel starts by sending a NS to resolve
>> fd00:175::2. When it receives the NA, it flushes its queue and try to send
>> the initial packet. But instead of sending it, it sends another NS to
>> resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
>> the user sends again the packet, it now uses the right nh (fd00:175::2).
>>
>
> what's the local address and route setup? You reference fd00:100::1 and
> fd00:200::fa with connected route fd00:175::/64.
>
The test in done on the dut:
+-----+ +------+ +------+ +-----+
| tnl | | dut |.1 .2|router| | tnr |
| | | 2+-------------+2 | | |
| |.1 .2| |fd00:125::/64| |.2 .1| |
| 1+-------------+1 | | 1+-------------+1 |
| |fd00:100::/64| | | |fd00:200::/64| |
| | | |.1 .2| | | |
| | | 3+-------------+3 | | |
| | | |fd00:175::/64| | | |
+-----+ +------+ +------+ +-----+
On dut:
ip address add fd00:100::2/64 dev ntfp1
ip address add fd00:125::1/64 dev ntfp2
ip address add fd00:175::1/64 dev ntfp3
ip route add fd00:200::/64 via fd00:125::2
ip route add fd00:200::/120 nexthop via fd00:125::2 nexthop via fd00:175::2
Note that fd00:200::fa is not reachable but we expect to see the packet on the
host 'router'.
^ permalink raw reply
* [PULL] drm-misc-next
From: Maarten Lankhorst @ 2019-06-20 15:42 UTC (permalink / raw)
To: Dave Airlie, Daniel Vetter; +Cc: dim-tools, Maxime Ripard, intel-gfx, dri-devel
Hi Daniel, Dave,
Final pull request for drm-misc-next!
Biggest changes are the remove-fbcon-notifiers branch and modeline cmdline parser rework,
and the addition of a new KMS driver for ingenic.
drm-misc-next-2019-06-20:
drm-misc-next for v5.3:
UAPI Changes:
- Give each dma-buf their own inode, add DMA_BUF_SET_NAME ioctl and a show_fdinfo handler.
Cross-subsystem Changes:
- Pull in the topic/remove-fbcon-notifiers branch:
* remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon locking
* assorted locking checks in vt/console code
* assorted notifier and cleanups in fbdev and backlight code
Core Changes:
- Make drm_debugfs_create_files() never fail.
- add debug print to update_vblank_count.
- Add DP_DPCD_QUIRK_NO_SINK_COUNT quirk.
- Add todo item for drm_gem_objects.
- Unexport drm_gem_(un)pin/v(un)map.
- Document struct drm_cmdline_mode.
- Rewrite the command handler for mode names, and add support to specify
rotation, reflection and overscan. With a new selftest! :)
- Fixes to drm/client for improving rotation support, and fixing variable scope.
- Small fixes to self refresh helper.
Driver Changes:
- Add rockchip RK3328 support.
- Assorted driver fixes to rockchip, vc4, rcar-du, vkms.
- Expose panfrost performance counters through unstable ioctl's, hidden
behind a module parameter.
- Enumerate CRC sources list in vkms.
- Add a basic kms driver for the Ingenic JZ47xx SoC, which will be expanded
soon with more advanced features.
- Suspend/resume fix for stm.
The following changes since commit 52d2d44eee8091e740d0d275df1311fb8373c9a9:
Merge v5.2-rc5 into drm-next (2019-06-19 12:07:29 +0200)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-06-20
for you to fetch changes up to 836334fd747595331dcdc7709b447ad8134db693:
drm/todo: Update drm_gem_object_funcs todo even more (2019-06-20 17:11:53 +0200)
----------------------------------------------------------------
Boris Brezillon (4):
drm/panfrost: Move gpu_{write, read}() macros to panfrost_regs.h
drm/panfrost: Add a module parameter to expose unstable ioctls
drm/panfrost: Add an helper to check the GPU generation
drm/panfrost: Expose performance counters through unstable ioctls
Dan Carpenter (1):
drm: self_refresh: Fix a reversed condition in drm_self_refresh_helper_cleanup()
Daniel Vetter (38):
dummycon: Sprinkle locking checks
fbdev: locking check for fb_set_suspend
vt: might_sleep() annotation for do_blank_screen
vt: More locking checks
fbdev/sa1100fb: Remove dead code
fbdev/cyber2000: Remove struct display
fbdev/aty128fb: Remove dead code
fbcon: s/struct display/struct fbcon_display/
fbcon: Remove fbcon_has_exited
fbcon: call fbcon_fb_(un)registered directly
fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify
fbdev/omap: sysfs files can't disappear before the device is gone
fbdev: sysfs files can't disappear before the device is gone
staging/olpc: lock_fb_info can't fail
fbdev/atyfb: lock_fb_info can't fail
fbdev: lock_fb_info cannot fail
fbcon: call fbcon_fb_bind directly
fbdev: make unregister/unlink functions not fail
fbdev: unify unlink_framebuffer paths
fbdev/sh_mob: Remove fb notifier callback
fbdev: directly call fbcon_suspended/resumed
fbcon: Call fbcon_mode_deleted/new_modelist directly
fbdev: Call fbcon_get_requirement directly
Revert "backlight/fbcon: Add FB_EVENT_CONBLANK"
fbmem: pull fbcon_fb_blanked out of fb_blank
fbdev: remove FBINFO_MISC_USEREVENT around fb_blank
fb: Flatten control flow in fb_set_var
fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls
vgaswitcheroo: call fbcon_remap_all directly
fbcon: Call con2fb_map functions directly
fbcon: Document what I learned about fbcon locking
staging/olpc_dcon: Add drm conversion to TODO
backlight: simplify lcd notifier
drm/todo: Improve drm_gem_object funcs todo
drm/gem: Unexport drm_gem_(un)pin/v(un)map
drm/vkms: Move format arrays to vkms_plane.c
fbcon: Export fbcon_update_vcs
drm/todo: Update drm_gem_object_funcs todo even more
Douglas Anderson (2):
drm/rockchip: Properly adjust to a true clock in adjusted_mode
drm/rockchip: Base adjustments of the mode based on prev adjustments
Greg Hackmann (3):
dma-buf: give each buffer a full-fledged inode
dma-buf: add DMA_BUF_SET_NAME ioctls
dma-buf: add show_fdinfo handler
Greg Kroah-Hartman (2):
drm: debugfs: make drm_debugfs_create_files() never fail
drm/vc4: no need to check return value of debugfs_create functions
Justin Swartz (1):
drm/rockchip: dw_hdmi: add basic rk3228 support
Maarten Lankhorst (3):
Merge remote-tracking branch 'drm/drm-next' into drm-misc-next
Merge remote-tracking branch 'drm/drm-next' into drm-misc-next
Merge branch 'topic/remove-fbcon-notifiers' into drm-misc-next
Maxime Ripard (12):
drm/connector: Add documentation for drm_cmdline_mode
drm/client: Restrict the plane_state scope
drm/client: Restrict the rotation check to the rotation itself
drm/client: Change drm_client_panel_rotation name
drm/modes: Rewrite the command line parser
drm/modes: Support modes names on the command line
drm/modes: Allow to specify rotation and reflection on the commandline
drm/connector: Introduce a TV margins structure
drm/modes: Parse overscan properties
drm/atomic: Add a function to reset connector TV properties
drm/selftests: Add command line parser selftests
drm/vc4: hdmi: Set default state margin at reset
Oleg Vasilev (2):
drm: add debug print to update_vblank_count
drm/vkms: add crc sources list
Paul Cercueil (2):
dt-bindings: Add doc for the Ingenic JZ47xx LCD controller driver
DRM: Add KMS driver for the Ingenic JZ47xx SoCs
Rob Herring (1):
drm/panfrost: Align GEM objects GPU VA to 2MB
Sandor Yu (1):
drm/rockchip: cdn-dp: correct rate in the struct drm_dp_link assignment
Sean Paul (2):
drm/rcar-du: Fix error check when retrieving crtc state
drm/self_refresh: Fix possible NULL deref in failure path
Serge Semin (1):
drm: Permit video-buffers writecombine mapping for MIPS
Ville Syrjälä (1):
drm/dp: Add DP_DPCD_QUIRK_NO_SINK_COUNT
Yannick Fertré (1):
drm/stm: drv: fix suspend/resume
.../devicetree/bindings/display/ingenic,lcd.txt | 44 +
.../bindings/display/rockchip/dw_hdmi-rockchip.txt | 1 +
Documentation/fb/modedb.txt | 14 +
Documentation/gpu/todo.rst | 6 +
arch/arm/mach-pxa/am200epd.c | 13 +-
drivers/dma-buf/dma-buf.c | 137 ++-
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 18 +
drivers/gpu/drm/drm_client_modeset.c | 54 +-
drivers/gpu/drm/drm_connector.c | 3 +-
drivers/gpu/drm/drm_debugfs.c | 26 +-
drivers/gpu/drm/drm_dp_helper.c | 4 +-
drivers/gpu/drm/drm_fb_helper.c | 2 +-
drivers/gpu/drm/drm_gem.c | 32 -
drivers/gpu/drm/drm_internal.h | 5 +
drivers/gpu/drm/drm_modes.c | 473 ++++++++---
drivers/gpu/drm/drm_self_refresh_helper.c | 8 +-
drivers/gpu/drm/drm_vblank.c | 10 +-
drivers/gpu/drm/drm_vm.c | 5 +-
drivers/gpu/drm/ingenic/Kconfig | 16 +
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-drm.c | 818 ++++++++++++++++++
drivers/gpu/drm/panfrost/Makefile | 3 +-
drivers/gpu/drm/panfrost/panfrost_device.c | 8 +
drivers/gpu/drm/panfrost/panfrost_device.h | 10 +
drivers/gpu/drm/panfrost/panfrost_drv.c | 15 +
drivers/gpu/drm/panfrost/panfrost_gem.c | 8 +-
drivers/gpu/drm/panfrost/panfrost_gpu.c | 10 +-
drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 329 ++++++++
drivers/gpu/drm/panfrost/panfrost_perfcnt.h | 18 +
drivers/gpu/drm/panfrost/panfrost_regs.h | 22 +
drivers/gpu/drm/rcar-du/rcar_lvds.c | 4 +-
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 4 +-
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 53 ++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +-
drivers/gpu/drm/selftests/Makefile | 2 +-
drivers/gpu/drm/selftests/drm_cmdline_selftests.h | 55 ++
.../gpu/drm/selftests/test-drm_cmdline_parser.c | 918 +++++++++++++++++++++
drivers/gpu/drm/stm/drv.c | 15 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 4 +-
drivers/gpu/drm/vc4/vc4_debugfs.c | 8 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 8 +-
drivers/gpu/drm/vkms/vkms_crc.c | 9 +
drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
drivers/gpu/drm/vkms/vkms_drv.h | 10 +-
drivers/gpu/drm/vkms/vkms_plane.c | 8 +
drivers/gpu/vga/vga_switcheroo.c | 11 +-
drivers/media/pci/ivtv/ivtvfb.c | 6 +-
drivers/staging/fbtft/fbtft-core.c | 4 +-
drivers/staging/olpc_dcon/TODO | 7 +
drivers/staging/olpc_dcon/olpc_dcon.c | 6 +-
drivers/tty/vt/vt.c | 18 +
drivers/video/backlight/backlight.c | 2 +-
drivers/video/backlight/lcd.c | 12 -
drivers/video/console/dummycon.c | 6 +
drivers/video/fbdev/aty/aty128fb.c | 64 --
drivers/video/fbdev/aty/atyfb_base.c | 3 +-
drivers/video/fbdev/core/fbcmap.c | 6 +-
drivers/video/fbdev/core/fbcon.c | 314 +++----
drivers/video/fbdev/core/fbcon.h | 6 +-
drivers/video/fbdev/core/fbmem.c | 399 ++++-----
drivers/video/fbdev/core/fbsysfs.c | 20 +-
drivers/video/fbdev/cyber2000fb.c | 1 -
drivers/video/fbdev/neofb.c | 9 +-
drivers/video/fbdev/omap2/omapfb/omapfb-sysfs.c | 21 +-
drivers/video/fbdev/sa1100fb.c | 25 -
drivers/video/fbdev/savage/savagefb_driver.c | 9 +-
drivers/video/fbdev/sh_mobile_lcdcfb.c | 132 +--
drivers/video/fbdev/sh_mobile_lcdcfb.h | 5 -
include/drm/drm_atomic_state_helper.h | 1 +
include/drm/drm_client.h | 2 +-
include/drm/drm_connector.h | 149 +++-
include/drm/drm_dp_helper.h | 7 +
include/drm/drm_gem.h | 5 -
include/linux/console_struct.h | 5 +-
include/linux/dma-buf.h | 5 +-
include/linux/fb.h | 45 +-
include/linux/fbcon.h | 30 +
include/uapi/drm/panfrost_drm.h | 24 +
include/uapi/linux/dma-buf.h | 3 +
include/uapi/linux/magic.h | 1 +
82 files changed, 3551 insertions(+), 1030 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.txt
create mode 100644 drivers/gpu/drm/ingenic/Kconfig
create mode 100644 drivers/gpu/drm/ingenic/Makefile
create mode 100644 drivers/gpu/drm/ingenic/ingenic-drm.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_perfcnt.h
create mode 100644 drivers/gpu/drm/selftests/drm_cmdline_selftests.h
create mode 100644 drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 03/20] hw/i386/pc: Let e820_add_entry() return a ssize_t type
From: Michael S. Tsirkin @ 2019-06-20 15:29 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Yang Zhong, Eduardo Habkost, kvm, Marcelo Tosatti, Li Qiang,
qemu-devel, Rob Bradford, Paolo Bonzini, Samuel Ortiz,
Richard Henderson
In-Reply-To: <20190613143446.23937-4-philmd@redhat.com>
On Thu, Jun 13, 2019 at 04:34:29PM +0200, Philippe Mathieu-Daudé wrote:
> e820_add_entry() returns an array size on success, or a negative
> value on error.
So what's wrong with int? Does it overflow somehow?
>
> Reviewed-by: Li Qiang <liq3ea@gmail.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> hw/i386/pc.c | 2 +-
> include/hw/i386/pc.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index ff0f6bbbb3..5a7cffbb1a 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -872,7 +872,7 @@ static void handle_a20_line_change(void *opaque, int irq, int level)
> x86_cpu_set_a20(cpu, level);
> }
>
> -int e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
> +ssize_t e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
> {
> unsigned int index = le32_to_cpu(e820_reserve.count);
> struct e820_entry *entry;
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index fc29893624..c56116e6f6 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -289,7 +289,7 @@ void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
> #define E820_NVS 4
> #define E820_UNUSABLE 5
>
> -int e820_add_entry(uint64_t, uint64_t, uint32_t);
> +ssize_t e820_add_entry(uint64_t, uint64_t, uint32_t);
> size_t e820_get_num_entries(void);
> bool e820_get_entry(unsigned int, uint32_t, uint64_t *, uint64_t *);
>
> --
> 2.20.1
^ permalink raw reply
* Re: [PATCH v1 5/5] coresight: etm4x: save/restore state across CPU low power states
From: Sudeep Holla @ 2019-06-20 15:41 UTC (permalink / raw)
To: Andrew Murray
Cc: Al Grant, Mathieu Poirier, Suzuki K Poulose, Alexander Shishkin,
Sudeep Holla, linux-arm-kernel, Mike Leach
In-Reply-To: <20190620114116.GE20984@e119886-lin.cambridge.arm.com>
On Thu, Jun 20, 2019 at 12:41:17PM +0100, Andrew Murray wrote:
> On Wed, Jun 19, 2019 at 10:22:58AM -0600, Mathieu Poirier wrote:
> > On Wed, 19 Jun 2019 at 05:07, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >
> > > On Wed, Jun 19, 2019 at 11:38:12AM +0100, Suzuki K Poulose wrote:
> > > > Cc: Al Grant, Mike Leach
> > > >
> > > > Hi Sudeep,
> > > >
> > > > On 18/06/2019 14:21, Sudeep Holla wrote:
> > > > > On Tue, Jun 18, 2019 at 01:54:33PM +0100, Andrew Murray wrote:
> > > > > > Some hardware will ignore bit TRCPDCR.PU which is used to signal
> > > > > > to hardware that power should not be removed from the trace unit.
> > > > >
> > > > > So, how or can we identify or discover such system ? DT/ACPI ?
> > > > >
> > > >
> > > > I don't think there is a mechanism at the moment to identify such
> > > > systems. But if we really need to know this information, we could
> > > > always think about it.
> > > >
> > >
> > > I prefer that as we shouldn't systems that are not broken.
> > >
> > > > > > Let's mitigate against this by saving and restoring the trace
> > > > > > unit state when the CPU enters low power states.
> > > > > >
> > > > >
> > > > > I prefer to do this conditionally. It's unnecessary on systems which
> > > > > don't ignore the TRCPDCR.PU and I really don't like them to be penalised
> > > > > while we want to add this support for *broken* systems.
> > > >
> > > > It is conditional. i.e, you may disable the operation using a kernel/module
> > > > parameter, which I think should be mentioned in the description here.
> > > >
> > >
> > > Why should the user of coresight need to know if the corresponding
> > > hardware module is broken or not. I prefer the firmware tell OS.
> >
> > I think using ACPI/DT is the best and simplest solution.
>
> I certainly agree that it feels wrong to have a default level of support
> which is targeted at broken systems. However the penalty (latency) for doing so
> doesn't seem high - seeing as this only effects users that are actively using
> coresight (I assume self hosted mode is only used as a debug tool, rather than to
> obtain metrics during normal use?).
>
Do we have numbers ? It's always helpful to have lowest latencies possible
for wakeup and adding extra notifiers will always add some latencies,
so it's not 0. We always want to reduce there notifiers and hopefully
move save/restore to hardware/firmware in future.
> Adding some broken tag in ACPI/DT seems like a good solution - assuming it will
> get adopted and used in systems. The existing "disable_pm_save" module option
> can be renamed to "enable_pm_save" for those that have less control of their
> firmware.
>
> Unless of course we think it's unlikely we'll ever see hardware that isn't
> broken - I don't have enough knowledge of how likely or not this is.
>
Sorry but even then I prefer it not to be default and force extra work
to the people who add support and constantly be reminded that it's
broken and they are deviating from default behaviour in the kernel
which may come and latency penalty.
Making it default may hide the problem if Linux is used for some validation.
Also we hardly have 3-4 platforms in upstream that support coresight,
and many are broken except Juno. But that doesn't imply all others
are broken and we just can't derive that unless we have more information.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 03/12] block/backup: add 'never' policy to bitmap sync mode
From: Max Reitz @ 2019-06-20 15:25 UTC (permalink / raw)
To: John Snow, qemu-devel, qemu-block
Cc: Kevin Wolf, Fam Zheng, vsementsov, Wen Congyang, Xie Changlong,
Markus Armbruster
In-Reply-To: <20190620010356.19164-4-jsnow@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 2183 bytes --]
On 20.06.19 03:03, John Snow wrote:
> This adds a "never" policy for bitmap synchronization. Regardless of if
> the job succeeds or fails, we never update the bitmap. This can be used
> to perform differential backups, or simply to avoid the job modifying a
> bitmap.
>
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
> qapi/block-core.json | 6 +++++-
> block/backup.c | 5 +++--
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 6d05ad8f47..0332dcaabc 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -1146,10 +1146,14 @@
> # @conditional: The bitmap is only synchronized when the operation is successul.
> # This is useful for Incremental semantics.
> #
> +# @never: The bitmap is never synchronized with the operation, and is
> +# treated solely as a manifest of blocks to copy.
> +# This is useful for Differential semantics.
> +#
Again, this is too buzzword-y for my taste. I don’t find it as bad
because there is not much to explain about this mode, and you do explain
it above, but still.
Like, I (me myself) read this and after the first sentence I think I’ve
understood what this is. Then I read “for Differential semantics” and
I’m confused. After a couple of seconds, I realize what you mean
because I’ve described in my response to patch 1.
One reason it leaves the buzzword-y taste is because “differential” is
never explained anywhere. bitmaps.rst makes two mentions of it, but it
too just assumes I know what you mean. Also, incremental backups are
just a certain kind of differential backups.
So you need to explain “differential” somewhere and how it differs from
“incremental” in this regard. Why not here?
“This is useful when you wish to repeatedly perform operations in
reference to a constant synchronization point (when the bitmap was
created).”
Or something.
Max
> # Since: 4.1
> ##
> { 'enum': 'BitmapSyncMode',
> - 'data': ['conditional'] }
> + 'data': ['conditional', 'never'] }
>
> ##
> # @MirrorCopyMode:
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: CKI hackfest @Plumbers invite
From: Guillaume Tucker @ 2019-06-20 15:42 UTC (permalink / raw)
To: kernelci, vkabatov
Cc: automated-testing, info, Tim Bird, khilamn, syzkaller, lkp,
stable, Laura Abbott, Eliska Slobodova, CKI Project
In-Reply-To: <1667759567.21267950.1558450452057.JavaMail.zimbra@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4496 bytes --]
Hi Veronika,
On Tue, May 21, 2019 at 3:55 PM Veronika Kabatova <vkabatov@redhat.com>
wrote:
> Hi,
>
> as some of you have heard, CKI Project is planning hackfest CI meetings
> after
> Plumbers conference this year (Sept. 12-13). We would like to invite
> everyone
> who has interest in CI for kernel to come and join us.
>
> The early agenda with summary is at the end of the email. If you think
> there's
> something important missing let us know! Also let us know in case you'd
> want to
> lead any of the sessions, we'd be happy to delegate out some work :)
>
>
> Please send us an email as soon as you decide to come and feel free to
> invite
> other people who should be present. We are not planning to cap the
> attendance
> right now but need to solve the logistics based on the interest. The event
> is
> free to attend, no additional registration except letting us know is
> needed.
>
Please do count me in as well!
One topic I would like to add to the agenda is:
- Open testing philosophy
- Connecting components from different origins: builders, test
labs, databases, dashboards...
- Interoperability: documented remote APIs to let components
talk to each other
- kernelci.org already does this with distributed builds and
test labs, it would be good to apply the same principles to
to other existing systems doing upstream kernel testing for
everyone's benefit
- Optimal utilisation of available resources
- Enable more high-level features by joining
forces (bisections, cross-referencing of results, bug
tracking...)
This does have some commonality with "Common hardware pools"
and "Avoiding effort duplication" but I think it makes sense to
keep it together as a general approach.
Thanks,
Guillaume
Feel free to contact us if you have any questions,
> Veronika
> CKI Project
>
>
> -----------------------------------------------------------
> Here is an early agenda we put together:
> - Introductions
> - Common place for upstream results, result publishing in general
> - The discussion on the mailing list is going strong so we might be able
> to
> substitute this session for a different one in case everything is
> solved by
> September.
> - Test result interpretation and bug detection
> - How to autodetect infrastructure failures, regressions/new bugs and
> test
> bugs? How to handle continuous failures due to known bugs in both
> tests and
> kernel? What's your solution? Can people always trust the results they
> receive?
> - Getting results to developers/maintainers
> - Aimed at kernel developers and maintainers, share your feedback and
> expectations.
> - How much data should be sent in the initial communication vs. a click
> away
> in a dashboard? Do you want incremental emails with new results as
> they come
> in?
> - What about adding checks to tested patches in Patchwork when patch
> series
> are being tested?
> - Providing enough data/script to reproduce the failure. What if special
> HW
> is needed?
> - Onboarding new kernel trees to test
> - Aimed at kernel developers and maintainers.
> - Which trees are most prone to bring in new problems? Which are the most
> critical ones? Do you want them to be tested? Which tests do you feel
> are
> most beneficial for specific trees or in general?
> - Security when testing untrusted patches
> - How do we merge, compile, and test patches that have untrusted code in
> them
> and have not yet been reviewed? How do we avoid abuse of systems,
> information theft, or other damage?
> - Check out the original patch that sparked the discussion at
> https://patchwork.ozlabs.org/patch/862123/
> - Avoiding effort duplication
> - Food for thought by GregKH
> - X different CI systems running ${TEST} on latest stable kernel on
> x86_64
> might look useless on the first look but is it? AMD/Intel CPUs,
> different
> network cards, different graphic drivers, compilers, kernel
> configuration...
> How do we distribute the workload to avoid doing the same thing all
> over
> again while still running in enough different environments to get the
> most
> coverage?
> - Common hardware pools
> - Is this something people are interested in? Would be helpful
> especially for
> HW that's hard to access, eg. ppc64le or s390x systems. Companies
> could also
> sing up to share their HW for testing to ensure kernel works with their
> products.
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 5521 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: rk3399_gru_sound: Support 32, 44.1 and 88.2 kHz sample rates
From: Mark Brown @ 2019-06-20 15:41 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: alsa-devel, Heiko Stuebner, Xing Zheng, Liam Girdwood,
Takashi Iwai, linux-kernel, Jaroslav Kysela, linux-rockchip,
Collabora Kernel ML, Benson Leung, linux-arm-kernel
In-Reply-To: <20190620134708.28311-1-enric.balletbo@collabora.com>
[-- Attachment #1.1: Type: text/plain, Size: 663 bytes --]
On Thu, Jun 20, 2019 at 03:47:08PM +0200, Enric Balletbo i Serra wrote:
> According to the datasheet the max98357a also supports 32, 44.1 and
> 88.2 kHz sample rate. This support was also introduced recently by
> commit fdf34366d324 ("ASoC: max98357a: add missing supported rates").
> This patch adds support for these rates also for the machine driver so
> we get rid of the errors like the below and we are able to play files
> using these sample rates.
Does the machine actually need to validate this at all? The component
drivers can all apply whatever constraints are needed and do their own
validation, the machine driver is just getting in the way here.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ASoC: rk3399_gru_sound: Support 32, 44.1 and 88.2 kHz sample rates
From: Mark Brown @ 2019-06-20 15:41 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: linux-kernel, Collabora Kernel ML, Xing Zheng, Benson Leung,
Jaroslav Kysela, alsa-devel, Heiko Stuebner, linux-rockchip,
Takashi Iwai, Liam Girdwood, linux-arm-kernel
In-Reply-To: <20190620134708.28311-1-enric.balletbo@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 663 bytes --]
On Thu, Jun 20, 2019 at 03:47:08PM +0200, Enric Balletbo i Serra wrote:
> According to the datasheet the max98357a also supports 32, 44.1 and
> 88.2 kHz sample rate. This support was also introduced recently by
> commit fdf34366d324 ("ASoC: max98357a: add missing supported rates").
> This patch adds support for these rates also for the machine driver so
> we get rid of the errors like the below and we are able to play files
> using these sample rates.
Does the machine actually need to validate this at all? The component
drivers can all apply whatever constraints are needed and do their own
validation, the machine driver is just getting in the way here.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [Qemu-devel] [PATCH 2/3] seabios: add ati vgabios binary
From: Gerd Hoffmann @ 2019-06-20 15:11 UTC (permalink / raw)
To: qemu-devel; +Cc: Gerd Hoffmann
In-Reply-To: <20190620151104.2678-1-kraxel@redhat.com>
Built from master (commit 6e56ed129c9782ba050a5fbfbf4ac12335b230f7),
which has ati vgabios support merged (checkout master branch in
roms/seabios submodule, then run "make -C roms seavgabios-ati").
Temporary exception until the next seabios major version is
released (probably 1.13, fall 2019).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
pc-bios/vgabios-ati.bin | Bin 0 -> 38912 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 pc-bios/vgabios-ati.bin
diff --git a/pc-bios/vgabios-ati.bin b/pc-bios/vgabios-ati.bin
new file mode 100644
index 0000000000000000000000000000000000000000..79644708ff88014f127aad29b707bfc8e26aee06
GIT binary patch
literal 38912
zcmeIb4S1B*wJ-k8<U0&`2MBb40Y(LiRA@lOpd*Qd;AeC+2ER%hKC%aD6iQ}Dyao)N
zL^Fh@w*PzV@m@I>#dD9R$6G0FA)wVs!U@5q2xu`9iV-QyI4MNvfdDace{1di&PNEg
z=RWuUJpbqU_a!s$yZ2su?X}lld+oK>-tSQI^ZP=MhyO_%d^umDoV({24KBD!+I5xu
zznX3OdWihLQvUU||Mt?($2uR=v`v}GTK7y%YpVZSYg$cO&fg0A|3x@aBK&`v*)ZnN
zOLd1lrqg0^i&^75QCu7FOcrlz`I<J+?#U7Q&LjBj6Z%`9h~~>l8(JfiHhivihsTJ6
zpXqPCFZ{oIMIbXx(>5c&Pxw2<6LIJkiDI{CSe!2W$J`qiTSRlW73dC$j21B~&={C1
z{9`O8;qP^tJhnA9XOjM31L7{>>pm^~t*;1Q>$f(C&A-YLyFrfD*dp$oT0gOt9`qgi
zruwt$G&J_zxaJ-aXb}JWAG(FVs8{$~#N1CR#({)FtGLUJUKCn{snsn^g}rWZVX?(6
zeCw>5XGUWSV2aZ5<wdPeH+421Irn;Fr&~mdtZtD+fDMKCLcQ?s#G~Bo_hiG52>&UN
zx;K5Z@SW&Gjmmz>N=b~b=O&ONz#L7Bhz-Xhk%%VzhsCUj&|kk`70oBD!hcp|ToxPN
zN0A1?OAd$)ztjF7ot_teB>Zh+!%40^g)7fGgqkg=30`I#7Q<Do!cMVazpCXuDh`G=
z9cT=QChY|c?VSdNZGp`fe?R(Czj#GFE_{1#GCJ|2vOe*>r~nvLXA57S4pH#+S@nNt
z1;fw1A`YGemekEibiE>;>`KA_rECsc#JedVPrOav^#=k$<ae7ud*KP;KOhbUku(ec
z$Ebg5GqTt9fa_&F=K6!e_nGb%dkcGMy4PGx^$Zuj<7S}0L}0yQH|5uVB0fCM)qQ&-
zsGn4Lf=YuJ%)KICyq836zbr09sKsvK|Kt^6`Vw#-mUW9JLLmHKiVwTNfB;o*D8a}#
zcuxq^Szu@Z2C7SqbR&N;5Hth9Cj?p8BTN8>&;%8jFtvko*#_spw3(tI%eq?B?bB=b
zCMAx0sqpUw7Hy_`V}7c;zVK)0Sb&Ip1Ei$U!#1~QUbig?KzCw>KrH=*ucN)4cV=;`
zC~l}sri@20Yu-96Oh<&N1=0ipe+L5ni{Er_e8f_7DM_y#Yp%JJtk?cKZf3pqSEfw|
zP}#c;eSbwXf0l$X+ZlkwBr8$)^=5QU_>Z`P^S%Ni??2Koya8rG<{Ao-Y9Qe&1pdOG
zId#vqP9+4Gln1*({t!aY6cd7kfjdm17uifg{w|Mav-t3&xL^1Wih~!?NYN{D%$k|y
zZ;B6t;+g{xuRszqk_uk|NXhHsWlYy~V2;0V3y3RulLqVynpoFBE+LA*-zyIG2~#JH
z=KyoF!TY9LT<3iq0Otu=12xqS=Jjq?_%OFf18mVe4pG<T887Mrp4psZ_Kp$0%Vw_?
z6Ts}v4BMfv#H>T%bSYEY)5WZPZZWrTi#Hv4T=vUkF}IcG%E8aY+&29m0wUvp$Y>WC
zP$LcAH{A6LZW#&nQ1}LtH1sCovv1uS>3W@iAhZr@kY_1|W>yyleaFL-0NzmehAX(d
zA01B>1>gsU)OR`E`{|}b)SqoMwyaQ_k7H<qB;+)-q|FN7bOo1O4o$&K)OS2$pc>mR
z{2_of18jFXkGCHXNkDav_Z(Bks<-*`q|KY4XrQYZwLuzYjsFvXdEW%XT|w<KiRT03
zgf9f;slNp@7zYf3|Ew$c`6cl-jW~haX(#6V=x3aG02-NKf#=R-JVEj?q{4K-6@2TG
zC<yPT8sD3Ul4Brk@#|38ka&rPL;xHFMn+PI1~JQSTl{9l7^40SEFbz?7*$gt5Vnd7
zzyKa=o{7SL5du#zV9Z_6Fp(nQF`*--bKxVH)}?XNTFzuzOrU+$>NB-rVx30Jx7P-q
zvE>|UY?&$=##BSU90U|edClf<mRi>ucwIw5FU@*%5vl{L5%gi=isf&H%sulBv3n2n
zm}oNVns#RUe$kW+zJ;%W`UV4`nuM?2EMd+-gfWrRk(0cA|CuWmKVOfPm%j$D#qBRV
z>Gl_$Fpv|jGiU?2aZARUjhlvcWs7D`(=0}IDglAbI|{ADaj0znVknGW=yHtM4$>vV
zuy$n$Qya$OJPk-;Ix<sOW%{8pA;h;WKH<4Vyr*r6L>fsI76A<wSbVJux*G~lZaUJ~
ziDmW(Nj9`CFRvJ`!k{DEI+$o8b6fJ6oWPmw9X(=KCdhol<T3v;E5?shv3oy(N$%m6
zVx^RCkM)X?-Q58|p!qd!j0VeWdyJP*+18p%CeNfbqcNVOVE=1?RTAcxX)}~T6PTri
zvjKNkD%i14Hc6`IVhoFrYpEeVTT5ZNOnsHVH)g#6xoNHW%%s=-NULwgN;nCH4f7yj
zk@U4yH5bz=D`37fe}REMo>y~eQY8(>m-rlkjYad^v>93kZ2!PB4ieui-lN&fiy2Q~
zUu$G@7}~29>#4NegfDCs&7WhX=~eZqT613#O&N@6Mr$|;Rb9a@s85J$r<kI_Ac3G|
zLg+e`&<#6t1v87qLtJkw)!R1ew3y$6<?b@-U_K+SndRs*5F|+sJq8pplapuJhpu4l
z04VJQ#c8hKqo~#<c5#=`H1kyo{V1rGGo)}6=Mf<R6>YBI1Zr`cMfl%`5ee(m*9uPg
zj}S>0whforoH`FixPn;*fh8B9=}3v~C_GR0sUM3_bGI2w1q~{Ze5Iuc8vP%;f<ONX
z{by`}uh56R;$51)RFRNJ*$A4B#7*Df(QYV9l8kb6!`FkQpjGTT0@(z)J=+7!⁣N
z+namp(GF!{VZMC29^Bevx{{fo>O--c>QiM%m%kUVr|a8K59$SRjhjoXL9C)WXir?g
z65EMoY<u7|+PrXDwKxPXU~@NkAzgdL?!9Q5TB|$nnId-YBSISYPIcEO$y<R*-OU)C
zByoTEFw>RD29hbVV)PyNlFtwj-v?X1z<9P?+zerfh{r(BMR$F{XxuO1K9+cbyA5<K
z#xmCvCu4FZl3QSq*d9kB(Y7&35_*~w1txVjqr+Dr@ges{*JyWr$yd0K#eD#G8}1QW
zoAn)c5!Ed*s=or&KLFK35%wSrxW4mJbkHE+r;*VmOrMImm-Qe0NCU=mn+`-7@ulL$
zm%v&zARea{OTH9O9x7r9J}XuRenv7#rT`@R9PBAOET0y!p``}-n?>^_4AlYOrM$JN
zqA3qq81!@aoW<wMt2DHI0Ip9#s5}y-bDQJzkHlZD7(IUrjngCWi25=rGoTeHnFAyA
z-4?MpRP&|sHL2IWOUa%^&t>6m_LM*Ogt*7!#Ukpvl<K**`rEjtd4{p_3EEx3S0nP#
zhE+&+1%IlNa8)SjQ%NX2N_te%B9mn*34KbXi&QdMChz1VN@y~L=0@TzdA0%AkP*$n
zWKS{-6sV4m#r2<}KhSOd!d_7qSwEcCFesGQdc^}_s2=F)UZpl5*r8z(CsvH~+I?_z
z*te;<nB;N5e%y_PN(+xcp)0ip1EcRav=)T6q(S+^r#=vqWM|si6bMK7n}$^a*aK7D
z4fl<7A-lf4Ih0=C0YxUK3=GgjJ^OY(8ft8v+A!xHzD>Ljf(0?7C5)B{tOIP}n>xwM
zBl~Z^Fj3J#SZ9Njhn!QzBsYNlq~>y3<x}L@HgOw)sauw6xvk#3`cE(~&$)unfW>=V
z!S(156jGmfkCsr<k(3|Rkyy^(hmP!1tBsCTT%v=qA(itvk<m8Q?e~m#CHmp4Jq_=5
z0hR(K#O(C2-XO~u3I%=_ytaAp+GYjZZ3|L<t--tV_2qld!e&9!m?r4`+;bJ9#V%?a
z<65%K6&wxQr!_x(3<_|;6#{RxOKu!7k)^^F{0Y=(%eD+!5g}*Y?CAKK;S6O!IqEwu
zi+8zmZBzYN_+7!J0B_zlQm#?&)0{DFcKb_Clm7qnwlvCjH&7CFi~d~SqP%4?(bGWn
z`&<DH<r4|CdL^O5()DBiskae&p66m@^VIq=h@`YlZ5VS8>6Ug3^&v3C6+HiE<Zgvr
zG^M4&E5DrXnLr#s@4rZ*6_PpR3k;wWQXM@WC*`RZ;%5%qqGa4#A=zeUl4n|F#z4DX
zn_>=aOL4+o?Mim0>UFQDU|Pqik<h=AiCCQMZg@7U`3(6t@a^@T1(0bt?4~|uu6tvF
z1@WTVUX2hfF*)J(He$UzLTnqkSv0ZjaF@F+8KJGZfcGzAmR#_k{|k&>vPdyVn6S|N
z8XP;~7~$;^@4+qxo{Qr8g9OkcKI{WavG!0D!JWQf)JQQOdMVx8B^C<bK(hB=4O2D2
zcs~>ReX`NyC^Qc5k$SP?;UtVNP+h{{nZzz`?0UGw$3@1+EQjgd&Nu=oh}DOc)1(@E
zEBq4!>u=$%={pJ}I!WUNxSIOTVmk<b7J&o*x)b2xI5&k{nxE=PLiReamVzgU`&}2a
z%=MjYny(9<`?<J>piaORUl$B_s#bp-8YhQ<d@>BdUW10YM8nPkyKupus=$a9jB7^x
zhn8y>cnDMw9I#u1bU%SPu*ae>Hiy~=AQbb-dZy97*NU$K_^|L3$lYit$TASYorB~b
z`~p}pOmBV6u^`i4IP{1Sxi=Qe0LUa02S6_321%&ZU|M@J++ssvujasbHfc@KA;+kh
zyt6RyRvH$lxp&hr;9m+11JwG5&_@?xkDJ`}_hGC^HKcpHLlHByto3>52vh+fPqq)h
zi-x+2)kuo3aV+$E^B@{f^M3E`By22W?u~@szhC%HLb@Pt92m(sYc!caGep1|de)4}
zan+KdR3M@ft$56+`21P$lqB454dt8N8}A*-J;&<$nF-x)7A6?|<a%JhcED9dgs%A%
z3|_1^q%<@7D0<O+JQWiih>Gnz1aO>Ltcu4qLm$W?IgDZ@SmbS=&{(#J;d|j6Qy~P4
z9BznJ1BL%cw*C;qNwEwmuNe3z#x=ta;YEque+tNMXyY-gJEYfEnIN?a^C!Z8K?-b=
zw<p{UQJ;A53~EAD;c7xuE<#fATwq5GQi|k*@e)dc6)&YtB&ELzv6T8RBCg#`%~Ie9
zLcF1c5((Ip$R`jCgBqfyX`#IYiy482@1=0w&SFwuh~d32HJ4|hGugA=X+~rm8mn#O
zW{-^nw#w(Z05niiSWm;Fu#oLyjn!;;L?3VJV$ZoNyi(3Tnl!!CH~9QLXka8l_^3{!
z(W`kDG(ri}9LE^Tfk2GrZ1^*-OH;Z{n3^RbFk}%wjl+|gxUU6?C2<Pc2o_@*9aH}p
z^zCwhB9I`kT5E_h$UCPK%?~V&Fc5Zuk(#(0s(Bbx^FHriK>dyEKK<fLJdzfG9W@ow
z>n}(j(&+H@OvXZs@}dKVeE{G29V}!!Be2ChYp5CjB^43-2sZM60V}bDb@zcm$1yTR
z2PiV)ZYw0s&T%t>y5nMP*E7?hm+nk;rd3{pnF$N*^XJ?--?{lD!D6(cu%j=AhY^6g
z9);o0z@o`lm<7_ma*$CFXBfT8gdQLrJXay?MB^XBS%gE!BqDC(4Wh*p26Y6m6-xf|
zH21~@6TZL<fj05&aSUP)xpR{-n-S;o7a<A<H<k%Lit3dE@cxtB{>5KlfOl}T1}QkZ
zhQan~9my=JK^y3Afk7qG(y-`nwS!xIZbZVZ<WcxbE`hcn#wm(C4YV->VgoL1qDS2I
zMPFj?C*57Y_#Ev4;ZAyKoi%FwG)!cMbWsS_3+4}lft+1`5cUoD@m+(dA$x?(6&S7<
z<@3UH-o3HtOIPsP|3EKiLi95s$KW95t?3}!Jk(2S%D)(Eiyz@IN}m%Z1Xumok$NJE
zxaChnSdw4I$r)e$?VQ{vna7+g0Vlz|!ai8UR@ii>iHk{bTx>pn6)yUEz_+5agZM}b
z=Q=Agv%%EUL-A9ueUbJbh@)c+j?yAb!3^?BMker-HVY1ZMhk0EP`s<bHgVUiJFR)r
zgdehV5+2EZ2L$spaS~y?jYSCZzIM*wKRO12n8)z@$GRKg7x|&1KSrqU^tpc%_al~D
z5)2<l7o!9innZ=l;0J$<kQ%(`BFM^J@T#fLcV)vb8Z8XpWh1r#(M*>p!1vj?$JW5X
zWUCK$wE@#Gk*(S<Whu6V*y@ItqX@hnbnPd-i`Wnh0Lm>oE3U_W=0So*Zrypkv7OYD
z-q?(3q3>{E3!qEPeP4eCQROai&4-Y;PsQ$h=rTm^HjY^e54r^UOW#p70x^2cJDhy~
zN5q3-QT@U2)9Y`oZx`2hVn4JVd?76h@pW%3LI21*`dvS<1?gV5x#X;@SuBCVa{vP3
zIx!)Nu{A{)Wo4@PQ?4j0fGkxfhPde~Ahr&nycNrNf3h_yJFha|F3sJm`(~L)5U})<
zvTy~%K_m-1*s+Z&!Rs!;WPlb~cN}vQ`U6uFGT`^Nvx-Gch<`H#0}KD&!UJFxNt8u<
z<{J>o0@ATr?wT^ob6jddDeOwrL@UifD>WBDXy4ne|LC7Jh!YZsGIzjmv*+;ki*MZl
z&2tYaW<yPq60bf-g&P+PKM7Xv6-_mS7e+k!Td=+A`aH>CkHtN^WUssa;o&F69m01p
z-TV9SRDg8F;0d-<!N$QIqxRw#0?RqE&>bl}5qc;BR!6s02Z=VK2(1th%$5(}aey)m
ze6a~enK`O|8|JVcJWpY>$H1Ue?8T24kC1=}SN%a6Q(hVKC=Bzs6bo1InqFwXMVa7h
zy5_NAZyf8M3S_Q>uY8Hjzi=itxHlG^gB6)hk*<7qJ;Gi2U<?JFr3V<8d%&CSZcEbK
z0|ln5%gaN&@aj8O!^wcCW0dqA`6FDxQtTE;1+eo88)<SohrTY-zMotsdNDRVMEbqq
zPyh4yX*Xgpes<Fm@NfF7_<cQ(#<T>yZVHA-WdT*9`^K1j5v%@!&a(e&;SWO{w0;De
zm=+^f@Wu;L+L}*7=)G)6{2B~^lz+fGEfC+fLIf1_o$SYK0nLlC>DUVxxMsI4-m-21
z$@eR+;Nf19(ze3aHTOmcVeKK$h^Xkf)3Fa+U-D}unK(K@=>-$^NI?t#f;17CI&#Nw
z56DAE-_%E%yAaKR(A)n+QI+O1G>forx~XIf4TQe4Ph5{61C*TUBB1A%yyBUTnY9IT
z%8dK#xM$?HBRo|gHe9CtBJVH5$zp!E1Lj6J17G!>?u})?hMXsyfryK}U{m8#x@T-<
zS`9*XH-{(JT*~x}t+_PZJI>vP7}s?Weu%Xlr!nf2!lT^-`KGXr{-u*84!WTSAB|3k
zjakt2{{1vjat~G%z%{L>Df5K6F#vN9nhFZ`LGeiaCp51qc2ReMw5a$#O1O}U&}}N(
zMh41|dXQH7^m?);OAs31Nx{J@j2Y_HW97z*4TK0}!4vq4lIA{0b8199foXLKGxH+)
z(B}%C0Q6OY&uE0F4vsru-eJ`9v1((*+=u`+Law-vV6A{bD!@We3<II$jJu)2RtHPx
zUc2XRcVhv3P&lpry%5U1rp+~<nLT4v?p<(Kix4>DBKUCM2cIa-nwn<b<1{nwM=&A$
z7P+Oc8fa<7g0+!?mN)baH6x3qflp@~Ha!M&7190Of#n#*9I^XF9GntQ?!yM)K`e?D
zC!vI}54963WUChuTWp^A0_M%(S?~_B!haMSF4ed-%`*wI$B@338w}{rc~hRD*{Y4-
z8#3Z*yco~|R01CcJHa^I^M*;U{VnwH$LIH$ykl`ZpfIQ*q^Q^aH+aeWWK1SB*W?OX
zP9PX4(>yvo<P9|x!7oNs#eWt_Jl$cEn};f8-hPC(PGnKi_V?8jB0BpNwJ;HQ&-S!<
z``@vZfMpST8YCcucR^+f&)sD2K@}XLcs^}HHNrhpjo*R!1Z+6JKwDI>4*X{sCLT>D
zqZ#Y{j6;){AD{e5?xb=nW3R(J^<B=!X%=95n>IfQ&5_e$_Xl#%B}ULKj48uQE_G2)
zV>6b8HTjLrm>ZyX{(Sl>psxk=RT%ok0Jp>Ou?6V}&>1^vv<sKfc}8^)en!J$Fb6j;
zNZPnCgJul}Z<#x1h=UE^%@<80AoC#YOwK;6wj;1m5wjHfOs;@n1MQE|YCP6^M5rxV
zU-!U<%O7C_wuR!2yIat&(~65+JAXV^_O*}T+Oy8b5I>xA9jH0PYi9Qe4m@RhyW=b0
zg;h{(lhJn7tbN<}$Eq(#zeUj{iOTSP4wBc&Vdmaq!<n}2<yO%`2-6Yuh`o9m43&bP
z#P(_GW?0VXGt>Z$`9g{;c!RV$;D8iqnG<^LOcNdUg5ve8B|_yQEq2+7d+*-OJdB-A
zBLM%Wqzvqv#V$l^0aJ@_<M<jD_g8moif9aY!L=A}=uSSiK>J+6Up$%8uUbqpSul-E
zu@g4{N!*Nj8S%4xWHkm9CH`aLJt79EOL~mfqA)U|5hdw8A}IkfN>KwSGD6^6cWYuw
z1U+{JYc9i@-1?5jG&K}YR#f|O*g|DZBdY1_Ae|3^aoJE9d;?+Nts0bp=K;9^NfV7m
z3j&?Ay<P1%nzpy8C#Vh{6+RoaSF9kWLjqjE>pvHdBXGqN!<U3%jB>(rJ5YLiKpeC+
z#u&zuMpG6e(86fi;?UH6E*_PTP%X6Ecp3*KlX1s7=N8{8>>X0$VlA@3D!2?NHa#w3
zVCk#_t#B8<L_0a|`cZUDDH&!IIr8r&VL63){;k8<m!iWC<Xa7P!g=jELxN%<p({*>
zb%|wIubpCcPJw%;zZ(c$1}{;fgcBPNZG~qXXcnMJ_06<YDVGU53jQx^E@o8DaOQYZ
zD2ibdPqt(dEk%IAz6G`!eJuwzhha_@o`I=;2&6S3&;|B7%e~`70pY|GmNM3U=FP}h
zX#S<ix!mJ^Zjy7RUYluhF5}?-6us^VlW3X(9=L)F{}5Vga#rZI-!wgUqjR-hmyby|
zfPS?lQ@`>=Qx3yT{DWw!;-~CC$YV}e_(IQXPOm4&S>-7VrBi2bsom#I1y7P;;^6!y
z%<gA~i>4V|@90N3I)tei9tps-L_k;Y!GX{b66rLWwY|0ERlZwv#xp|^lTO6oWD|zz
zI&7O@bbj%<aoP&=-xVA<9{L$ZI7T^TZu~s-!}v`7T^xjX_@nUC5Eyh32R^tpu&Mw&
z@ID@2e^Q(zT=Nl00w`GA8=f5xl!vNmkd_HF-mc)q55=9~9)q>v52;2v9RY!X7}sEW
zsN*a0H;kA;)UP3rhIUr6#EOL_G&-9A7k&oON{+RHqMeu|F1jbl{ef(XnA+$I>v^QY
zE>_&n6^qG7b#R5rvO<AF-LGZ4kh(v0vqWN%VOP{o7c2Z+f0U|!h2`bzNhY54<7mi(
zV#OW?KG{!`1f4}Toe>D-B<%M3dTg+ws222xAAw(&SaFam{;z)C=<>tN`xIMA)OXL6
znc`KLMjI~w6y}ir!w-^imgdPomPnyAop^iUon+X}d=53VHHG3-IFEzf5juDXg-;nc
zPemErW;cy)Dsqc)7-k2&XgWy+6Bp;2Db)UuSh49*AYO5tDH=~*0Y9Pra6q$eShCo~
zo2u_=IDZlz>D2YQn__uTJ+S2FAYki13x>8lj7>5EM6}l5Cx%1pG4@>I+AK(Z)}4R@
zk%We6*ATG4O)Lp=1sW0rT<8!oW*;h2&^Mhy8VH1_>IOFmKo(Ap6(V*?c}+K9*<)y;
zfO1IH_G&foJ4P`A$i!PXMvNeWD`-C+jW<6G?JUlO#+lsb3wzCQS9VM74XOT@V>40n
zS*&#D!OQGhq87lhqsjun(X>ONDVwMHzN5-Mljq>5YQ-3_3rhio%@$-u5-fle?-vX)
z6-Ep%@PJ9qN&w05hG_`LvB_ziF5CW*w13VpX%nFasiK}xajZ8its5wv(`<d>Yz4@{
zG3X7ah$DKfmV|0h_ulI^(RM9P#8{Q9vx~dG+p(IaVeiKz;E<sT61AwDJxg*H6*BBq
z6@E&TA}$LN<K-Q@W$Suy;!Arj9h;*Y3wy%Jje%{EsjuCw$(``VW*U^<DcXQr3@hxJ
ziX|I{q#xm1+%}Hcg|lME-(wKoF}*<1Y_c&k4orP*7e#(P)w~X>L8lLzG3HW;roM)q
z=w`X!9G(NBo=8Iyu^2*if{qAWp1PH4KpJ)|h8IARMY-ZGRTXRX)=~&3B2}NFxTqUn
zB_~|L=^sRWee7tvf~L;K)~Q>U!Rcq%;MA=g^2X9Og;<QOK9d-WxO#Vu@C6-!eeDIn
zZo4@3wR#E^Z1Lk8rO!=$&Ce?`+b%g>iaTv=Gx)!QqZo3B_!RoO^?vHxtV7suU#e}|
zhXcD-vD@)eG)5CT<9%t!RKp)!47(@GW2?Dr_1uJQcklI4=tj(DOEg7<#@EFQ6te=M
zg{CL~q#*pq%F#|7EWUhM3Ntp%F#AFSmz_4RE_Oi`Xvo4@&rtZX(?MBK1e66MGSrDU
z**<Jnhd#I*opCOnaZq$E%Sq9}R@-oS5j;Bmg|{@CglOyeev&7PGK*N$vq-;<RPD_=
z1Oo=~K_$G4s1g4qSMWPWu()g(Ai>jrJfq)`ZLI8Hirr<<qpslGBUphJhCh+=?-@1F
z?ww4iGsz;=^3mUG6Oy9If#7u*#|{jb8uV^f;M~83-tHGG+Q`&f@g{51^Q=h^Qs5mY
zh1w%SS!IS7ij|>Ntau$SNr@HLEh55RKF>?ziibIGKIhe)$2##{vEn<l1gvmz-Ve?r
z-2Ny>IGX#gX5_p?E9YI1!ktgpDN5e_S-RM;4=kt=yZbDth~ubdw)g*eX2YEPm*)0*
zCv1m;q^tpCWzBzSZo4;gQ#%XK#G77{nqyn*>Fs-P5)~tTMy!~@ovh(bKEXuv{0A!r
z)jHOTBv69Nbua`Yq$}Wn@!4Wpc3{cjy_5Y`q6i*}BnlLXKT|3Ej=jQn3P8Oe3}$D0
z1Vva#I7v{%D&Ob56e^dQG;Mnbh#q>ya46s!sw;upgzqFyxpRpvzQotf(Q>d3G2v{i
z#*Yw@zV0+K4BF|8fUkQJKck$YNGq0dXCr?>XB~<~IP4=?Ws`R-f^y-0SB5dLV$+)*
zcz=ZA&E2~1w-^9k3YBRJC3y<Mv_2VM_oo7~=qO?wxR(T7!6~%cM&<%7W&Q)M;BMGb
zShz3jP1C%0Z;15ep{VF+<-83SBYI^n7>yHEe5U2CbzmfG!L-fs2Y6}E2#X$eVdj2P
znFhsqD%C>*kJA!-vSP(QaUaM3g`|r5NCN-|57um3R_NA<Vq}~+k>K3^*n@iA7?W7B
zlWYI+oB$W1JGiu>Vv)y6BJaF?E6=CA`zkPzU5K+0zEdXQi$G0w@jFd`-q5N+xx`_@
zP(dOHCIG!E5pv$$aP1@B9j;)2;~5e;j^)gX#MK4~W@VF{k-|nNNH|Yg2as!zMZMaC
zlkpjCLgIbf6<qNdGs92O5uarhh^9Cu=Dz0rNn#TTo7L2HV^ZpMdy=;0Ls}ZfSjpk_
z9sfZ1-giv(b8`EG(BoJI0^8H^u#o^*wU^-u86v9TUx%8+V8t~28`>t?U1I&;w0tp_
z;`l{-Bi<s|`ucKmyL%~{9(q799(?P1Cg`>G<f;_*K=r-2f;0+6G@2+12hU5d{f<f8
zPLVae_8}<DR>(*?Evh%r4(L8H_n@~M0iprD_9hdGD#!$2gCK}hK`J(8x{=ck+{I>u
z8;_C#&m>u|J><1*dY|8lg8{<)OrtG?!tQVm0cC93kF#X@jy|F-$fx-5w2t_m)`%9c
zKX{7fDIbBp3%Pfis0PCT%PGo%?T7XHDDr3$J+~J#j{If+oiKA?hS64rZ*PiRnT!|%
zwQY|QMp!Z!*ulV=V%J!3E(Q!VlcUhUcAeNoc3%R(w0MA9#IB4u0Js`7uYHBR`Jtx=
zXbHrc#V0q#lb_t+_PtHxFsc$8kROT<KSx}QqgPh%XM_{u>UarTF;>y^-G`0wJ^*>)
zqI_D9u*uqsQ!?l^&d4D~I@wiJq}TnK&gEgtGX?xPi-Q~l(n<k9*sXKVR_G|RAbRnE
zFkMDyzNfZJufux0o8ejr)uU+`)mBo9q%^Ih6hFX}M{oj5gIIBxr~feu7G%@f^R@$B
z7VlEW#e<8)_ambC`<grQoyk}b_gF8%P5Kb~-8jAi-ILL(oI}|DzP_(2U9{D6FSZ?5
zWIsX+V*MFf5P23hhm&C&=DtME19Rb}p}0VYeFIi;JLw5@eSoVniz&d9^O7;cQni^I
zv!EF0q-yhL8I&CmbK5<`zzrL{8J8c1Wr6GqM=%jnwISAVcTLp@Q{}a|SxuGW#qNA`
z7-P|pwOgzCQ@$t7-IhNgDVz>D-<xlLz%)b@g$w`$?(LW&J<b%p_T|*dX>{=Lk13VI
z;aERGhZ|3uLI<$P1^}E+9N=S)lTt&!O@|imN!M#TaDbz*r&7nk$J!^c1FF|1rG@@S
zI{dfVPt%;E_1YQf&P==%k}h_&KZ*g_T@8H~+L%t}JSNP};$%!bY479c8BCg=Bi*#9
zu=oy)yx&X-dZh>RXnrzGDRRGd&B4&1>OP$IVp;RwlL~E^mAzV}G7&|G*4TS3MRrI-
z0TV(wc((+0ei2TM66$-hs16p;Hqjii0{=ZQ?C!Y&GrXt8S7eS8yMAy*=0x5lNEyH=
zsK|zRmDXk2Y#;&<{JfDW!OcdX_1kzvE|d+N;8%z<E2@y?3Xb_RSv8P)6ajR$+M2-G
zUU6GtPsO#kt?R8A4~3VB)yI=bz47blty$#53(g9EEH^bsp76>m<m2lr+z{>r3*>s6
z7J4rQiqx!*KJ1j|y`HtfNLf+O)K&Gcf#~n6If1Q+e>o|;0NZaA!E9xihkIxl5B)S1
z5nt>Il1WRp8y#+gt!G*7yNIRq5NJiX2|AV|nv2YQTbM*Q|NY4bSh5d?#KKg76_JL&
zBa=%PrmJwKe_<vTA)bq;i&-Qvp$`y@@GrDLU!%_5=u8pq=2RuSg7@O^p1!l>By5ob
zYEK7-iaeqQ)h^F>(kkIEJW4HF@!U{!k|-L9ndSDcN63e1*?0%m59sTKW1zzCz#OAz
zIt6fdDiCw>er)1kDL~#xxS#bUKvTbHy!1o~dLou++iKABF^GDr1O^y{cEetJ{dqIq
zrltVt1)>D!-%3u>+go?8nSxih5GZR7V(O65`d%`GjaJxh+!55i4c}o18)OGP&d<DE
z+lC34qEvj-w^1CLo<hU2EuBcPi`~$ms$$5R0*b7w33a!44?{+>>P_BuTNtlYyiG~g
zW9(MfAX%yNnr^DZ{KC2t#_?3F^;AMFfLl@k_`L5z3hU5VleU1Li^eDLh%XvfbJ6N~
zs?uI_QTIN80P9IzwvESN3ch+W!%J!|+B_3#E;?|UifA`e^=}faO<I{8nLUXWC_=R;
zOxt7KmLC2Vff%_O<<cS*&W_JcrR-tbQfRDt<uKySHS8w#ppp9>FmWhV5=3gzHSmAY
z^0o4Io%Dl|KN(Mc989QRGzCumMiQ9%`yqtBb=@#z$}w1s8@HlvlFj?4VR@gmj~{QK
zHvRYKpcOKz=@~&zG)jgTFy1U1n}a|!<7TpMNgyj%g3Oh-TZt^%1Y39;kwu5C7dokG
zA(6H4_RvunV0`)<%jj;Nuv>%V;bG!iX>HqZT!RiX_Aa)E-Sq_%+-(K+2SS-ia#A)1
zcpt`3C)lO^-obdD2$FILJ<AQi0z)aCgT|q5xiyS*g-u*&>xGExb!*I6YF;SEJAAYS
zhk$X{adO@2A2(xZ=>@=zCcMp;iftZiXc~;cgd_D|^|@=FwW9tFvGXSK9AY01OzO3x
zVNf8j`S|bQ_QA%oBFa?C-L_$_LEQz?;-)>Hh5+=ub|Rqe6Eud@mwV~W4x*^tL`3il
z2>klo0FpL2duf(_iDY)DPIH>QZPZ4wExawpC_V#&H)_u7wKYJDe*Sw0O))Y<5o1Op
zd%2Ni*x@d);)f&duUH@{#rInPOQe+>$VLfHgI=Po2|6s{3g$}ECz{-QF;ZISdnRX%
zUZ<PFIP-zxf0b?Ery8K<B1A8%KfF<)ULEhHE`<>l&Byem@ny0DL|N@ViXCc*Af-A@
z`U`Js+(c5SA2A*#c-oo?7|FWVphr~gEfhNI)*(3~LQh2iZ_Uv|%OghAZK^ECS%G34
zEjzB0(r%`ZS|~pv2g{R+U+WkjcFo*kS%smyYvz{Ws|Etzd_t9E3XO$F2wBR;A-*&f
zYN>=_Oqn=$jdKM!V$JT-t{Qa5FpopW2bgqIc)r;64jUuC;)SWx75t|l6=|k0UPNNe
z*Yr))RGP?8u&m#xG&KD35cU{{wfXdgG^-{!hv~IPA)~KpWL*8qRJoLls|r)4gZ8Sj
zO)#(OQt_S@W}__*U+Bd>WNSTc!kZv<CoN)^i~OYB>kL}Yo&v3~`|)k#Zv-`%dM)$^
z3!-GTe==2$B73Y2uI>8~vdLOZq0JU&hF<G5lQs4eERG4&>Ao)K2)%Z9O69H2EWP%)
zx$-)v1!=Q$xL&s$#t4KOD<9G63ZDBA<7y9m--392?eEQG>GhjK^DNGBdhM>v$_dVq
zdTlt}IZCgaKDe28|LC;qwR?u?KRlD^d_b?u7!2^e|G@a$DI^KoC2c)S*aEvFJQ|5q
z+A+Te(n6btc{n(OwJRS(0rj~N9xMtn(ODC;f?azisb+soJVXC{5=Tx(K-}<dC8p|@
zn54d1s*&WQZ#xQb>g)Ua&^OGk9eZ#e9eREk6+B_byI}eY&kT$1?Z%zW#=APhVh47X
zBLoOV&a)dT<h4EQBNp}I$6XLNZNtyKEQL=(?!{-UF|jvGaXLCFbOzBXyuKWQPTlcQ
zJn^N5i<UTKFX4p)N%U_JJ>T(>s*T2B>KdES@kj7(#w^al!P!yr;4HMlj!$p|6MYRk
zuxKIuKgnQPgtK)x<Dk{IApV4vANCtw(g43h`d}rDGhjI714rQ-2w*-(GgtmV0(36I
zU#9SbL}3LMm9sp{FSOA+OxWr5wWOm!9&!4{9-|H&8=%fZF(Ob3nTE*-zD(Z3heDFQ
z!O#UbrYPe1Nktj4qN5p5E<8;>L2>9E*dkbbSZ0gm=-T6Xy5RtX!A=y%=e~<m8cL?{
zvL9(LlCG?~NyxU~1$T<0XS9>_BjeS32x3BLX$H{PX%_s@R5_iUB&~8dG-d67*YxLo
zTId%V%}J|?rr&rIW@BA}Ido2QeuE}x<&BsqwU3#|Q~DPZrcT{dS~u~IFm*spI$lX}
z3bEJ~jI@T{GC9ZUweOhpAO74#b1q<Vj@RqX$VHd>iZ{#RdsViF5JFRD>o5E!ot}$F
zglSIWF86Wbp<jUbl4^A~+-v4TIu~F&kW9fZ&AttlaQ+0WFKyvb0hKs;<ULBJ$Hql8
zdWXXQhPj4KG`y3;Kjs1dmVcNd^ix=>1|2g<viJ-QP7Y!-9_z$7B8?lS*MbmbrK9fH
zucX#~)y&6O_$*TLDA_V1K?=b?pp;A-Yv^zqz~g%}nKwo%M!3%xSWVt3(j80#86c{L
zB&><#EWXBXuyI3qum+lI169dbVqi*00p?A%&;fd{A-;;8Sa#JB`*|~bq1)jlV|K_B
z7NKva$tS!A3ESqHG^53iKz(x{1h0suu-egU3h+uwY{ssAQXq)H*1guy?*_!K9G3TI
zV8MqvQdtObWaQhX%9$j5N3g5$bC@K0?PU!@S@+K*ACLmJwtVe4C`3nn&V;t6lI9<8
zs=R}?T%Thpx|gM>nDu@E3Ez&25&RkrO=f<b221ZEymb7IbX7?Wh31g-)|yQav$|Z9
zvFpL+A6^xDh<5f8w)MtxW!d%6MUsu3f4$u&vPE$iQE&ibyD*DL8;l&o>I%N|Hc=L8
zOEEyD+z+CI_MtvBAg)Gf_?HI6)tf8g=0sB#1SdSxfWKOs_)P}|Px>%kk~ZvdUaQwm
zHC4`XIuLBpoY!Ej=7Af6H5dZw{}WbG9K!pell9u0p%aFioH=^kcjRb~z&onNl_OzP
zPOr>^CWm1sUai)`Q=KWEMQaM3sh;nUK6+krZ^CSEvabgDv=_~A*oUJ?*B4f|zt|kU
zU4l5k-ta8-O#GV?drr}k!((J}0%6KjMR>*<ix77{x(n0|W9l^ga2PU+ZAfmZB}JMY
z8k<aky=2&BuHcBHQeEsUhI??Fbs-Soz?_OUR%@Xzk|dv52C~INQCZkUqab!Or3<eH
z!*A2>c2Ezly&4Ru0pJ1o5Vu3F;N@R(T;m5xVwZ!b-h9lU(1S@dwVku|+6g9v!E!u8
ze<7?nt)6M2S4_^E^x8);DpO6)oAufsn4ELKZM-I{as3@se+5nhDaO3IOuPNpNjSC6
zR&F?z?=f3tOTDzJVXuUGVr~zaKg7m**01-%kv4g*Tcg)pG<&CG-CYH<$co>$lTS6!
zCRk|O)5Ei64yQ80lc97dG)x*7M@y#jC^Q^lzmUT9?80J+1xujodCveAd%YIgMqU6}
zY>*cG(is0XS9B4@ZZm@3-50QGhF2MIPDFojX!0{0IFr9x<Lmwk0NYzmhnF)9z0!T~
z_-1hdF(UkYn$aljRyPA1fU*DX*TQpRMZ7rU2P<F|`tTaE^e0}>!lT44E3^77u$q^W
z-y9{Ia%AY=FbcisrP%#j8ifY(zVJgxo*Q7wEWk6AHFvgU>T4V2!Zm`#)5VNg^9eb+
z;q2(hZGnG8Z(PGoB=qA#_W^x3qc<T&6S~1fVKwqaAxb#8;J?&}uoyLf*>>*dYOA}+
z@e<1#qFC)RNQvN;m)>$`38B&HQK8Lbgsmo0bv{IC{O}M(M=(-eKwWr620-QBxI9Lw
zex8Vgh597pF$7Ml=M)OLk;o$ivGALXdu4>^dOUErWjY>`2yPa2aD2F&dXnJdQxqAk
zV+|)CzYjjX_fDs|vLNc;U&ae4fvOwXyT{RM<=YcFdw7D_^%1jcA=ou&eKmK*=|~*c
zLImFhA$<sDbO{a;J(4;RZ<=-r|L15MXQR7uo(cPwM<=CWy5e_TaL|ih>3{The?z_Q
z|Fe1#{Cvq3?R{{mf1+?<<QhBAr(#!Mul<=evynCsnhwB5b&DS(@cv`m{Z+~MT8-tx
zzXEHn|54~WzYDgjA8(Fr!kf;*Upmdb$#nx&akzh+KN;f<Gi;A5_&gfM31BK}D4ixA
zf7~5ejj0@2?LY>hZ6LG_gtmduHW1ndplu|y5xn%$XcLcqARe6*vPB$@`%CV-FH>_k
z97}GWl9OBIa4c2#W$M0M-j`S4ep8jBOx-KwovK!>R3PfUbhS)ZsQWTiWhJG7!Xfyc
zsa1HqOC3`xZk@9HRwT+ijzxFg;dpA*@-oMis!R<9j-09~RW~@MEU%ife8!aJnc5?F
zJaqrv_uuK5;aK^!r)<sBOUfN(Yu2n<<5*tiDO=_#Tkcrmkr=PZ)QUYz)_5GnWlMl|
z{@o80JEpBITT`)e)zg5uK2xLIlDqF)a4V9TS{dP^s@yQOwZyaXR>#ui!Z9UhcGa!)
zHIs-b7fYjLIf~}r;8?jzrJs6AJ*v8E%AQ)acIDG<*(K^qv|!0{$}d~Ka=Bw^`KqOv
zTKTHVr^=qv?(lfZo?7jpLeDD4lJfFZ%a(Y+4zFYBGoG>v(C1jYa*1R0Q%^aTp_G7#
zrJ(L6ASd=!c$O@CGFnse14Yl2RcKGI(!dPn#G?6y(+aM4%+8rLE1I{UY;9Tjs?}go
zGz(ykJC-k54c2H6m93rWn5EIEfHRJ=Dq=L+1PBk=%BRID$C|Pqc*`n0U@4Jf6iume
zJiQ9PPq@naH250L#)!uNmwDH$!5A>E+o^Uj<YCD&&&suBj@3)t-~k4}v1Ix3HDwjx
z1NZk%fQVJ7#BI;NYZ}2^@2Ff-;aI-1V%d^4%gfMSaalP;!-28)fW8XH&`@`jvpj*>
z3szRFE?@GDV;KqJ(7@uw7r}$?p#$F4n&4;f<9oyhBspEavO;E5XfIZHmala$A#e$@
zc4^u7X64)@9(`1M(Rj{TqP@6c$<xcrsR#wp=UGdT60x#bvj?YdoRe67<IM@_S%csS
zdmO%;rGwHpX+-SmRTUnr416W0q~a_RuHmq=bXqVpQ&QT9k)zO8N-X4@WUa>hqA5Kc
z<y%Zx0&C3ODrGh$X^x~v&B<JrgfdD=$Yhjh$y$;uOQEF`DOr|EWiT;iSsIlgCCi4J
zQnh?jyQVYFES0iyN>?cxr>sa3EfR8sN=e9(DkULDAw`r)$ZVC8kfT*fLXJU-=#-G(
zP$>y%Qz;2KmQtWvLXJ}@2{~S+B%~ev%TL{=`Zob(l#=x(s+6oZNu^}Hd`f{64({z8
zNYOaR)O=2Lt5g9})IV9a04eH&OchcJbjs91q6Ii5ukS<|(IU(4LRn36sT!lZQAR0A
z=RGPV>AY8^B%SxEl*Hmi3hgCH$h9gZAuCl%LRN9gp&*}8DGB*sR7yfV%c+2ZtX3%r
zxlW}d<a(sGq|_?N=Tu5U)~J+(+<;V7%D7}n=MPm%Li$unLe?VnVyXdIr&1E~d6klo
zFCbNuwoT!zS1AeUS1Ad(5h*P*KUKEgpi&ZYlS)a*A5kjhfLTH|s+5HMu}VqE7m=z-
z%T=xaM5QF;PgP1n(zO2j^>+^ZodbX8z~4FWcMklW1OIn9Fijh)C1=21Zi;9f<(d`%
z`u3HG6X5<P?*E9-CVXi3>u-gn!#%Dc@YXB5<#BjnUH{Fn$)JKPLYVDL@200Dy(@rk
z8SvbPdoDgV;FI#7fK3H#jk#TetB`<qn!;<ry>A76eHR~cLZW@!7SZl|TGBv$6DT_X
zn0N5mhR<*uAtZWXPHXrbG0mX&O_UM6FXCQ}&uV<K082CshAmgHt~gkoVZUoKrNb8j
zUV{dL-3q)n;qJhP@LCmYvVt|nI3CubU`H@)H}I1G6q5&n{Tz6EArwdPA-p3Mtn`b9
zhBfexf{8CJ`E-dFyh3%Y6S#;E@8JFhKCj^OeH4&?a5cPiO54Eu+_Gi9C&#bp)k=W`
z*JD3=WVZH5#pe;_6KeS>IzOAtN#sAKXJihu4A0W<&~)v454e8#aLs#@v^!+oR~mmj
zE&rumTM6EzV>t2>|KV7zsxxe!mM`mkvFX!k+NosO9=DO5mOJ;>+nl%0%OiLV-L=^O
zi@S!q3IC$)DjdGL#nbd<yBSBcEC6_1M3eT?E-nL2Fs|uJ?2{EPaQ5gi-=Owpd~@21
z-=aPR7?A2`8}&1c`qoUzlXQ7mZSu;37fbDzY(V`7$jO%N>xw55<8WE`8;Ms!znY_M
z6YVX`Pm`iON0;?SjsAu?IW;Xtds2+{Sbd`XHL9PHq?w1JZIVG7%DGi*R@`{U#=?TW
zF>kgc^ex+{pKjEju1(jp>C@>8x6$-Cnyx(j8=aR&Uwp$O+Dl1E0S|`_8<v%oHDbhw
z?Cfl?(r&jSkU4qs<Z08U&6qJ`_UzfYxw#CVXVvm1X?fq)P#J&U&eJC4X;vVLFNn(>
zx?s|zyl+m*`}U-~TPEe@(cdk3lfIod>6>|p1#!7U7tENEH)}@ToEdqy&dAH7zgzQW
z%*mTED=)DiE_dhxO|z$I_AJdlTC>~fZ?s*@vTJGhsfGB0xZI%&va;+Wvh1U??6xes
zo&Ie0tkL$Y5%$D_xZI%&va{`DvhB8P`?zeoo&Ltzvu*b5G4{lQxZI%&pgEH@Yr1B&
zXjUuzS*#k=Vlp&id_i39&;^KIWTsm!>DH`tEBs<>dX_caVolGqCKkly4qY&8nAI}O
zI((Q_A7-`EpKcvC+&au+O)QAZ9lAiy&Z~SU%0JBkOoh=9M2#jx-gIsBbS)2aV*2zv
z%BB<wd8Tk4gN)WjL%>Hv#xZ%OkItK(H+njz4k1EKR6=FK2y|R^G(Z7IKwJ~ms1DFj
zZDb)q5Ik+ZZa(s?9Xx-zr-}Xg+Ijso^ZoyQ{6h>2hTuPSLDdX-4S`y+=0AlUV|SJ7
zYWV;ElP_M3^%YTK#J6K<<7xedf8Ma+w=ZwluwLe@k90*Mt*0UpmDaTK0bJF&P&4wf
z=2piiZBFN@Q>Sb;rz*BN*Q0VQjckCB&4CO5&l#>$t<(Troaq$v=L=b#Gh1K&?QdUh
zRpk@2#?7wkz*WVtnp5C%+R%VZ=iQi>gKKqfw@g2`3^v%ZW$sfa12V&A>vEoQb}9Ip
zKzDE7KwocnpoWXhsaX@}4a}REl`7Y3&<fPH^#;KjHHQm#iSD_suC8at)5YoPw$j}4
zwzl$IOIx)B;BR7?Oh)l3e#$giII5f;;~NCKECUu*$}l;l1Eo0<T7Cxt0fn8@lSM>K
zj+I+;bE~V3=8=uTtImxLUks3+Fg8xKFRem|h=@l;5as0q<@}+9%~svk5~xm1eZH;Q
z=s`=H#g<dr_B@rt+bJ*4U3(PcwU(0@no@o+z5vUY4evtJm1DE;WsCJtI3rHQZ3Y2%
zjJ7yUUm!VFfsW}9zG5}ZsYIU|Z^%z;Ygboms}eZPmRki}xYYPmw@L6eg%jyiXKHGy
zF}xPLv%F&fBu|tr4q!0)<H~bOk#57K#9;vSWuGN{H5J8`)AM@Nw<!6ht^qPezL7S%
z%jAJ;snH&Taz#94l~Nh?Se6671-*+QM8>gW$BqUReO40R0U}7k_d^1zN#gru+9_Jl
z!$6C{ufB3B6r#LOmJf)fE2>tME)|MjDqULI8(05WTbsC5rl}=vPPIqE$Cp!<Ph@F`
z&G(aNs;UZ&o|NUirF=!(BTa(g#HH|`JU?)3f2=>uYf7sAa{ma0qED3{K2~jE4};68
zkE%VCm*!ehqxB<QFDKATsQFU(nG_N)HG?_b)fF-H2N&5$3MIWL2P`ht|48feG<eOe
zQa5T&IbCvcRJjHXwmR1y)mKhAeJmC(r_q#nhxi7@oE$|~d~ubfIyzsq?$T1?HiRGw
zQr!jtF!*OjOXUDp^P7OG+b{`?^4#*}r94K8zbIcz;2qT#R^h;3zLxMS{z5c!nW3tG
zsi|5PrUNdhc~l0x6aWP;fn)pv$jJzFa#t6g<aLzL8~jF=9O77iWO;Q|1PuC&DSdRU
zh{*@nhXfe?v*zUV(~!)utJXA)yBEg~8uIA)0}4qJfG9i_LI9#^DL?B|Eyk4UAbqOl
zQx>|qni#~=$%>CAGcH-5$_U1`TBg??jp9`gJi`ri(0??aF`X@`%#n^n`XPG><B7^z
zf_wlzJ`HV?kj^d7O-O?VC%8$?If)*^mmn_?*Z4Hyi%(MoE0?;b<_8#;kS6%}@-}Kg
zY8Yyc$cayrS{x9i7<)rs0qE)5#;@-@T1oJlHm|&+V}M3<KPM%<G(yZRO=EgvX-RJ^
zom173AP-cYARnkt(4_Q9<+q`?@{;)5RH@M()}>aASF5oCMyJ=wex^?&VT$0Nk_V`-
z>ZM{8#Qz+ZXN^Y*Su{3VCrJn~Ab$L4ymPsjhlk7K=L^9n&=2{Fn_oz^848!%bC#FS
zi(ie%9MBZ&7$7GHN~kno^pEps4Gr*<{2HL?FCQVQZ8RPB|MyhOBxI?y*#FWz3BpSo
z8!=G?bILo*=R{Ko>Xjo$rbjGD{8#ex#D9ORO#H{3x$>(oA*;_8P0x|nd386a7)VGD
zhCiPgg*V`gJ5xO{sQi4Y(hZuX;G$`!3;5%DPmfXh6y3y0zEoPRHAb#R;uL>PG7<_R
z3a|1L;V0Rm@QS`$jQ;TbmYlq3OZ1SJlURO%{&&K-E23Q(R6h#OP>~os!(E8MGkt^0
z=gb+5KT5x9HImTYoH<c?86Wx=N1dj{^;hNR4XPi-C+Xqos#wRj!Q&O>A3H&DUj}_f
zR_~xoA9N|W1ah^tM>{(^k4pPoBj2jC11boLoi5mBn2dB$iY_w$>5?e`K&QplC*-aN
zx=z+E48n^qG;BasSbJ1<RVCL$g|i2z(n>u;P4Gp@Hfrv)OizS4JC9IG{Y07TvDmMd
zrT9)tMf%)&qd9v{DXI6;9J_)r^lO_@1CvGmsSM>_7&4*E=cp2chD3)gMmlReY1F}2
zeE*@5*2m0kGy)}wKY6h}RL`-Sv6x45Y{rw$=3P&Dxl{J1lUQR61%Os}=9IQ4icht?
z3=Cg;H@ttzPQ&+C%uRIs6Wo3%+&HHnK5e4Qk7C&amcOXGPo%`0eJYE&`kH2V`c+J^
z5)#E3>E#<vzVz|kr%nb4^a=+b{(YQ#KW|{3VJt^|ajK>~d&9Ah`t?*aq*rga^ieF#
zCYgdfP(5jw#YGPiUHL(dJmwe#QC-vEW=}H`i7x!W)g5?V_zdR`lO!$-kl?r*e*5!L
zx1GIqAt#05v$INoZCh&4fjh*XF6FM{PFK|TPIT4POp2=wzT_CmSYK6+;#s19Ufs6;
z*!h!&d0=?wQX-Xau54N5nJdH0@XIGMa^;n)GQ%gYmSybWqfeY7^}wHK3f{Qkj5CFb
zOd4Fk7#+I84F`#m%E2x;u)_nFwb>bobH5XeRSm`)``-ObOVm>5l=8ck+bz9p!wEKg
z?%r6vV}`?x?!~$HhPUlxNW<5bGw!4)FRv;uSB{zVvyB$oP7e$mCRAK6(d1)|O(8HY
z<32>)Csw{!_|_*G5@qC9sWDo={&7~Sk}_(FE;(ZIxm?AtD0TSoK(*9@)Nn45z&LrK
z03L~DpluVBcZ-r2!;_X}iEgyvMN=7#2_w7WD>9V-%+|DAOyR4t?<}cCb@H559}K@)
zExXd|G2~PE%yRrtk37;r{<7p5<S3WeB>Rx6eC2pg*%&_ti$Vft&%oishoc=kN}Li#
z4|$lPR8v`^cU&C}cd>6ArL($iwO#eWD*fV^Tg+ZVw71ln5fUK}2m=^h#b^X$ET`d3
z^o5nHW_ZHV5hgCMy5&9?Uhry8MORzZKRL@}f@f9K{q0cR8q-N?jeJkpBl7&>#ukvV
z6nS;ARMh7+dJB)&aCiwz3@2QvxD;WDE5mT`pz+v7{aj8FWUQ>MO?HT7KF-5M2O;j#
zzg0YgbH8>D?6ar2^M-HBuC1gD%$DO0WHBj_lo@4FpO*VaWpQJRdTPX=McUe=GLX7J
z6{!{=v>XUvEefYxhKZCL%Lbtl=I!g~=-bnAtfPaaHRi#RiAf!dah^sj#uqA!^?_1x
zbV4SgGLL6Ng%Mv8eO9*6qH_T=p8QpVO9W193*F^KzA8UqrgwDalpaO+Zl0#el-U1I
z(oJPqrAWJ~mFS|z9MrG#PX7kaw9gj1qF$!*Mb68+L3Ug!5%MbDDA!B$M5BJFYGFX)
zW)cSbpz)O14F5?HYgpd0dej%=QsoILsuiSBPu=Mj^}!S^Q4bO6M1M2U+f4K|6Ftpa
z48N3Hk9v{ZLe$4(8WPJA{Y#WdI*mRk3gs<N<}yU0Um5L@s+Z_fDvwgOKFFW!Q#IsG
zageO-*rgy;Mxqm$=t3%xc$DNn8tx+|Tz^|ze;|+#h^X(Vpq1yysVm$@_8O(WmbQ4z
zWmFy`*GqI4Nxh&IWoxjqfjcB!MZ;5MjY)Ok7aA5>qLZk6#2h=fAaw?mm`p*6<sT;#
zoWn%d5XuL-&~OZg@(ZI*F{XdKO9=ggKfYMo$VcN_Do7(mr?mJoJVEIQb|(0NS9pPc
z%>^XC51YR0$>YNg%6fA3Xp7fy@^Y(lDWlpdGoTLPX@C-A@78eR3<pk6)7L@SRylc@
zUvFc74elCyYVMPPmmi0}=zRR;nr?E=YBX~exn*X#+ltLrG7qrFs=*7R%~fsQGGYvG
z7-;L)gLl}K1z1FRTfFe|9<AYEMO`Z>XVOE)o+v8tE;IbosPaW|PE{2tcKArr3ZV^7
zNUN4p9jLPO<zOZ2u;qw0iXUS$bFF4XGce=`E!b$24URx51Xt}<vh@SRbV&!QUnV%M
zvA2LNNa@{FYdNdof8_Kd`eMl~?T~lcACa4j6Se+8pM}!!T(BBeY5g6LHc*Uc4gJx*
z+Cm|J@?v72QqUA2`ZNvA<BtTC=tMhMD#^To^AV^*|2sPRVT|;%!_kl71m6&1VJ`zd
z#sF>VEgg_|Y?V>@eld?0R8)g0MC9jGY2-l=J@6f1`JU9sYapLN`3tnn(q<gT;Az%U
zd$jL@<~xp7**Q)1syez?+o_+wmUvN&t6whQRXJp093D7LriQc?Q3w*Mpm8?YW~03-
zv<u@~qt08fm0!h*v1+g_ABpXMkrA<$c9*J!I0}AMbp+5ptaR*!k)2c3(GNc5meXcd
zFVZl{t1W%qym@sJoLtTQw`h_9-Ly$nev)&EF4$e<FyY=u9btULC!AI#4gewJn}{?v
zn+QJ(o@ULd&dIrn#*eBI9k`+Y5Xi#=Y%zlYY%3!l^k9(xF=u(dX3xp#&VfEdxA{W}
zWJT4C+7*$#v{|Y&wtLrWcGb`It<KbWA`jWbm-Sk=x}z_g20sFr8M%NH>r0&k$NT{t
z-#ZjPs@rlwf)n*6f5;w$z9ta`U<cakFRd!2sqviUxsK;(w*{Lm`%#EL;*W7B#7N8C
zl=avKBu3y)bfe#`6hy>?mgajE`n*06z%~cW%HC4gl&ITJ`*h&`rM3^+_QHsS>)W{+
z{pJ4TD*BiK)UI9O@8bc()amHyKiUyB4Gp6ZbEuT$1Q*skx@r9u3%2;$I*#2aI&|E-
zZdvs~k{kw`rXf?@2q=6Dh{3h>@}IHm&{f%Wnm#P9>Z_0M(kLS%;XFRn5N#q*D4)ua
zo3JT>Qk9lQ89?Wd8ngkrk1FGmcx`NaQ4`9TGRzYj843hP`CLw4$fbP3Crv8Dm@>>L
z!+<hOCuuYh7Q!=Ujx?00HJLVyBWV_KdxRWU9=B^4L9$&cHw+&#d4MNs>=^wb`jnMI
zP4F2b!=f>487ikT%)6uQWV=*#^mX)M1p7On_yS;`Tu=KuN^?jb%b@mZ!!QY;8Zkrb
zC&gKn)6ZfJeMS}t*&p^C8}vpM)nlV0)k62u0O{{QX)XyfU62<3hxq{E#3R%dv~xeX
zHPG7qT7ne;^MQd#zblg=&Rmd#g%)Yh$T;XhjJS%rf%Ix1Bx>N?;Npk)uQYS|DM+on
zByYrvu7bNCGFu;eP-4`Q?!(z|tp@L1EL(P~W7?escr*T{nYlA>ruXA-&Y3g&M#r>=
z@Y4c!;kN}if5we-uXik6`Lx%wvK+6&8^0<rd*<w0X52Ju=F%k<Wi!jlZ_(D2mCu+p
zbJpycIWuO@nc<#OcJrLF<+EnbT{icY8LQWnE%mM}_ssl3*;C$`tJb(RbFx9_-|v5&
G1OFTT`I+wk
literal 0
HcmV?d00001
--
2.18.1
^ permalink raw reply
* Re: ✓ Fi.CI.BAT: success for Display uncore prep patches (rev2)
From: Tvrtko Ursulin @ 2019-06-20 15:41 UTC (permalink / raw)
To: intel-gfx, Patchwork, Daniele Ceraolo Spurio
In-Reply-To: <20190620014410.18135.63392@emeril.freedesktop.org>
On 20/06/2019 02:44, Patchwork wrote:
> == Series Details ==
>
> Series: Display uncore prep patches (rev2)
> URL : https://patchwork.freedesktop.org/series/62232/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6312 -> Patchwork_13357
> ====================================================
>
> Summary
> -------
>
> **SUCCESS**
>
> No regressions found.
>
> External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/
>
> Known issues
> ------------
>
> Here are the changes found in Patchwork_13357 that come from known issues:
>
> ### IGT changes ###
>
> #### Issues hit ####
>
> * igt@gem_exec_suspend@basic-s3:
> - fi-cfl-8109u: [PASS][1] -> [FAIL][2] ([fdo#103375])
> [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-cfl-8109u/igt@gem_exec_suspend@basic-s3.html
> [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-cfl-8109u/igt@gem_exec_suspend@basic-s3.html
>
> * igt@i915_selftest@live_hangcheck:
> - fi-icl-u2: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108569])
> [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
> [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-icl-u2/igt@i915_selftest@live_hangcheck.html
>
>
> #### Possible fixes ####
>
> * igt@gem_exec_suspend@basic-s3:
> - fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6]
> [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
> [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-blb-e6850/igt@gem_exec_suspend@basic-s3.html
>
> * igt@i915_selftest@live_contexts:
> - fi-skl-gvtdvm: [DMESG-FAIL][7] ([fdo#110235]) -> [PASS][8]
> [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
> [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
>
> * igt@kms_chamelium@hdmi-hpd-fast:
> - fi-kbl-7500u: [FAIL][9] ([fdo#109485]) -> [PASS][10]
> [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
> [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
>
> * igt@kms_frontbuffer_tracking@basic:
> - fi-icl-u2: [FAIL][11] ([fdo#103167]) -> [PASS][12]
> [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html
> [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13357/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html
>
>
> [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
> [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
> [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
> [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
> [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
> [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
> [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
>
>
> Participating hosts (49 -> 46)
> ------------------------------
>
> Additional (5): fi-cml-u2 fi-bxt-j4205 fi-gdg-551 fi-icl-dsi fi-cml-u
> Missing (8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
>
>
> Build changes
> -------------
>
> * Linux: CI_DRM_6312 -> Patchwork_13357
>
> CI_DRM_6312: 034e3ac6a2d180d188da927388b60c7e62c5655b @ git://anongit.freedesktop.org/gfx-ci/linux
> IGT_5061: c88ced79a7b71aec58f1d9c5c599ac2f431bcf7a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> Patchwork_13357: 776298c3ec6b6f35479ec3ca194c3f11e809b916 @ git://anongit.freedesktop.org/gfx-ci/linux
>
>
> == Linux commits ==
>
> 776298c3ec6b drm/i915/gvt: decouple check_vgpu() from uncore_init()
> 6186c2ceab1a drm/i915: dynamically allocate forcewake domains
> 7c1c30e3557c drm/i915: skip forcewake actions on forcewake-less uncore
> a33912a9c7bb drm/i915: kill uncore_to_i915
> 64e9e429a365 drm/i915: kill uncore_sanitize
> d925fdfca22c drm/i915: use vfuncs for reg_read/write_fw_domains
Pushed, thanks for patches and reviews.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ 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.