* [Buildroot] [git commit] package/tvheadend: re-enable package on microblaze
From: Thomas Petazzoni @ 2019-06-20 14:36 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=a2cee5037f9a7dcb732c7cddb873537dae718068
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Package tvheadend has been disabled on microblaze with this commit:
https://git.buildroot.net/buildroot/commit/?id=e1a59357e4dfe8fe9c9119d4b2bc9e4ec36eb3d0
but commit log says that build failure is due to "some assertion
failure in binutils", that is true. But those assertion failures in
binutils are caused by package's Makefile itself that has been fixed by
previous patch. So re-enable package for microblaze.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
package/tvheadend/Config.in | 2 --
1 file changed, 2 deletions(-)
diff --git a/package/tvheadend/Config.in b/package/tvheadend/Config.in
index 5db644400c..909d955c02 100644
--- a/package/tvheadend/Config.in
+++ b/package/tvheadend/Config.in
@@ -1,12 +1,10 @@
comment "tvheadend needs a toolchain w/ NPTL, headers >= 3.2, dynamic library"
- depends on !BR2_microblazeel
depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL || \
!BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2 || BR2_STATIC_LIBS
depends on BR2_TOOLCHAIN_HAS_SYNC_4
config BR2_PACKAGE_TVHEADEND
bool "tvheadend"
- depends on !BR2_microblazeel # assertion failure in binutils
depends on !BR2_STATIC_LIBS # dladdr()
depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
^ permalink raw reply related
* [Buildroot] [git commit] package/tvheadend: fix PIE build failures
From: Thomas Petazzoni @ 2019-06-20 14:36 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=dd0907d465a0d82a4844e7aaf3eb3be69103642b
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
Package tvheadend builds using '-pie' linker flag in any case. This
leads to linking failure if toolchain doesn't support 'pie'.
Add patch to fix tvheadend's Makefile bug where '-pie' flag is hardcoded
making it depend on '--disable-pie' as compiler's flags already are
treated.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
...-fix-pie-linking-according-to-disable-pie.patch | 34 ++++++++++++++++++++++
package/tvheadend/tvheadend.mk | 4 +++
2 files changed, 38 insertions(+)
diff --git a/package/tvheadend/0002-Makefile-fix-pie-linking-according-to-disable-pie.patch b/package/tvheadend/0002-Makefile-fix-pie-linking-according-to-disable-pie.patch
new file mode 100644
index 0000000000..385c94b36b
--- /dev/null
+++ b/package/tvheadend/0002-Makefile-fix-pie-linking-according-to-disable-pie.patch
@@ -0,0 +1,34 @@
+From 5cbf08213222cb507d365e6cbda87277f0b8f31e Mon Sep 17 00:00:00 2001
+From: Giulio Benetti <giulio.benetti@micronovasrl.com>
+Date: Fri, 14 Jun 2019 14:25:08 +0200
+Subject: [PATCH] Makefile: fix -pie linking according to --disable-pie
+
+Only compilation follows './configure --disable-pie', linking instead
+doesn't, because '-pie' flag is passed to LDFLAGS uncoditionally.
+
+So add '-pie' flag only if CONFIG_PIE=yes.
+
+Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
+---
+ Makefile | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/Makefile b/Makefile
+index 41783b546..4e5a947a3 100644
+--- a/Makefile
++++ b/Makefile
+@@ -62,7 +62,10 @@ LDFLAGS += -ldl -lm
+ else
+ LDFLAGS += -ldl -lpthread -lm
+ endif
+-LDFLAGS += -pie -Wl,-z,now
++ifeq ($(CONFIG_PIE),yes)
++LDFLAGS += -pie
++endif
++LDFLAGS += -Wl,-z,now
+ ifeq ($(CONFIG_LIBICONV),yes)
+ LDFLAGS += -liconv
+ endif
+--
+2.17.1
+
diff --git a/package/tvheadend/tvheadend.mk b/package/tvheadend/tvheadend.mk
index e92c111082..b192a33d4a 100644
--- a/package/tvheadend/tvheadend.mk
+++ b/package/tvheadend/tvheadend.mk
@@ -94,6 +94,10 @@ else
TVHEADEND_CONF_OPTS += --disable-pcre
endif
+ifeq ($(BR2_TOOLCHAIN_SUPPORTS_PIE),)
+TVHEADEND_CONF_OPTS += --disable-pie
+endif
+
TVHEADEND_DEPENDENCIES += dtv-scan-tables
# The tvheadend build system expects the transponder data to be present inside
^ permalink raw reply related
* Re: linux not getting gpio interrupts on xenomai 3.0.8 on raspberrypi raspbian/stretch kernel 4.9
From: Harco Kuppens @ 2019-06-20 14:35 UTC (permalink / raw)
To: Jan Kiszka, Greg Gallagher; +Cc: Xenomai@xenomai.org
In-Reply-To: <bac8728d-459b-ad23-3bd4-362494ccc615@web.de>
Op 20/06/2019 om 09:37 schreef Jan Kiszka:
> On 19.06.19 23:52, Harco Kuppens via Xenomai wrote:
>>
>>
>> Op 19/06/2019 om 17:00 schreef Greg Gallagher:
>>> On Wed, Jun 19, 2019 at 8:44 AM Harco Kuppens <h.kuppens@cs.ru.nl>
>>> wrote:
>>>> The ipipe patched not entirely cleanly on the rpi kernel source; I
>>>> had to
>>>> make little changes in the patch, but not anything really
>>>> seriously. So I
>>>> expect it to be fine.
>>>>
>>>> I used the rasbpian kernel source because it has better support for
>>>> the
>>>> raspberry pi's and mainly because it has better support for the
>>>> gpio pins in
>>>> its kernel.
>>>>
>>>> However to help you debug I did a similar install using the
>>>> mainline kernel
>>>> source. The ipipe patch just worked smoothly, however to get the
>>>> gpio pins
>>>> running in xenomai I had to still port some code of the file
>>>>
>>>> ./drivers/pinctrl/bcm/pinctrl-bcm2835.c
>>>>
>>> What did you have to change here to get the pins to work with Xenomai?
>>> You shouldn't need to change anything here. If you did then it may be
>>> a bug in the ipipe. Can you try with 4.14 ipipe ?
>> I did try with ipipe 4.19 and when compiling the kernel I got lot of
>> errors.
>> Some I could solve, but at the end I gave up.
>>
>> See my notes on
>> https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/__INSTALL_FAILURES__/install__compile_vanilla_kernel_4.19_with_xenomai_3.0.8__assert_error.txt
>>
>> Maybe this is also interesting for you.
>>
>
> 4.19 requires Xenomai master. See our CI (e.g.
> https://travis-ci.com/xenomai-ci/xenomai/jobs/209347407) for a working
> setup.
>
> Jan
ok, I used the master branch of xenomai, and yes it compiles the kernel
ok!!
You find my installation description and findings at:
https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/installation_of_xenomai_master_on_mainline_kernel_branch_v4.19.33_from_kernel.org__problem_linux_gpio.md
However I still get the same problem that the xenomai gpio ports are
wrongly numbered!
And within linux the gpio pins are also not working.
In my other builds I fixed this with the pinctrl_bcm2835.c file I
patched for rpi(raspbian) 4.9 kernel.
You can find this file at :
https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/how_pinctrl-bcm2835_patch_for_rpi-4.9_is_derived/rpi-4.9.y.ipipe-patched/pinctrl-bcm2835.c
However using that file didn't work here, because I got errors about
irq_set_lockdep_class function. However this function wasn't even used
in the mainline version of pinctrl_bcm2835.c .
I probably have to patch it somehow to match the much newer kernel.
But I will wait first if Greg Gallagher finds something for the 4.9.51
build.
Hopefully he finds what is wrong with that build.
Anyway all builds I did for the raspberry pi 2/3 with mainline kernels
4.9/4.14/4.19 with the official pipeline/xenomai patched have xenomai
running ok. However they don't have the gpio pins working for the
raspberry pi. Neither in linux nor for the realtime cobalt kernel.
Best regards,
Harco Kuppens
^ permalink raw reply
* [PATCH] qemu: disable capstone for 32-bit mips with multilib
From: kai.kang @ 2019-06-20 14:35 UTC (permalink / raw)
To: openembedded-core
From: Kai Kang <kai.kang@windriver.com>
When build lib32-qemu for qemumips with multilib:
require conf/multilib.conf
MACHINE = "qemumips64"
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "mips"
it fails to compile capstone:
| CC arch/AArch64/AArch64InstPrinter.o
| {standard input}: Assembler messages:
| {standard input}:36033: Error: branch out of range
| {standard input}:36257: Error: branch out of range
Disable capstone for mips o32 in this situation as a workround.
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
meta/recipes-devtools/qemu/qemu_4.0.0.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/qemu/qemu_4.0.0.bb b/meta/recipes-devtools/qemu/qemu_4.0.0.bb
index f119215b21..76776098d0 100644
--- a/meta/recipes-devtools/qemu/qemu_4.0.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_4.0.0.bb
@@ -7,6 +7,7 @@ DEPENDS = "glib-2.0 zlib pixman bison-native"
RDEPENDS_${PN}_class-target += "bash"
EXTRA_OECONF_append_class-target = " --target-list=${@get_qemu_target_list(d)}"
+EXTRA_OECONF_append_class-target_mipsarcho32 = "${@bb.utils.contains('BBEXTENDCURR', 'multilib', ' --disable-capstone', '', d)}"
EXTRA_OECONF_append_class-nativesdk = " --target-list=${@get_qemu_target_list(d)}"
do_install_append_class-nativesdk() {
--
2.20.0
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 01/12] qapi: add BitmapSyncMode enum
From: Max Reitz @ 2019-06-20 14:21 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-2-jsnow@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1867 bytes --]
On 20.06.19 03:03, John Snow wrote:
> Depending on what a user is trying to accomplish, there might be a few
> bitmap cleanup actions that occur when an operation is finished that
> could be useful.
>
> I am proposing three:
> - NEVER: The bitmap is never synchronized against what was copied.
> - ALWAYS: The bitmap is always synchronized, even on failures.
> - CONDITIONAL: The bitmap is synchronized only on success.
>
> The existing incremental backup modes use 'conditional' semantics,
> so add just that one for right now.
>
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
> qapi/block-core.json | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 0d43d4f37c..caf28a71a0 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -1134,6 +1134,20 @@
> { 'enum': 'MirrorSyncMode',
> 'data': ['top', 'full', 'none', 'incremental'] }
>
> +##
> +# @BitmapSyncMode:
> +#
> +# An enumeration of possible behaviors for the synchronization of a bitmap
> +# when used for data copy operations.
> +#
> +# @conditional: The bitmap is only synchronized when the operation is successul.
*successful
> +# This is useful for Incremental semantics.
Hm, well. All bitmap modes are for incremental semantics, in some way
or another. (“conditional” and “always” just automatically create
point-in-time snapshots, in a sense, where “never” requires the user to
manually do so.)
So maybe something more concrete would be better? Like “This allows
incremental use from one successful operation to the next, and
restarting any operation on failure”?
Max
> +#
> +# Since: 4.1
> +##
> +{ 'enum': 'BitmapSyncMode',
> + 'data': ['conditional'] }
> +
> ##
> # @MirrorCopyMode:
> #
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v7 2/5] HID: quirks: Refactor ELAN 400 and 401 handling
From: Jeffrey Hugo @ 2019-06-20 14:35 UTC (permalink / raw)
To: benjamin.tissoires, dmitry.torokhov, jikos, hdegoede
Cc: bjorn.andersson, agross, lee.jones, xnox, robh+dt, mark.rutland,
linux-input, devicetree, linux-arm-msm, linux-kernel,
Jeffrey Hugo
In-Reply-To: <20190620142801.11827-1-jeffrey.l.hugo@gmail.com>
There needs to be coordination between hid-quirks and the elan_i2c driver
about which devices are handled by what drivers. Currently, both use
whitelists, which results in valid devices being unhandled by default,
when they should not be rejected by hid-quirks. This is quickly becoming
an issue.
Since elan_i2c has a maintained whitelist of what devices it will handle,
which is now in a header file that hid-quirks can access, use that to
implement a blacklist in hid-quirks so that only the devices that need to
be handled by elan_i2c get rejected by hid-quirks, and everything else is
handled by default.
Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-quirks.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index e5ca6fe2ca57..48ed4caf0ebc 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -16,6 +16,7 @@
#include <linux/export.h>
#include <linux/slab.h>
#include <linux/mutex.h>
+#include <linux/input/elan-i2c-ids.h>
#include "hid-ids.h"
@@ -914,6 +915,8 @@ static const struct hid_device_id hid_mouse_ignore_list[] = {
bool hid_ignore(struct hid_device *hdev)
{
+ int i;
+
if (hdev->quirks & HID_QUIRK_NO_IGNORE)
return false;
if (hdev->quirks & HID_QUIRK_IGNORE)
@@ -978,18 +981,15 @@ bool hid_ignore(struct hid_device *hdev)
break;
case USB_VENDOR_ID_ELAN:
/*
- * Many Elan devices have a product id of 0x0401 and are handled
- * by the elan_i2c input driver. But the ACPI HID ELAN0800 dev
- * is not (and cannot be) handled by that driver ->
- * Ignore all 0x0401 devs except for the ELAN0800 dev.
+ * Blacklist of everything that gets handled by the elan_i2c
+ * input driver. This avoids disabling valid touchpads and
+ * other ELAN devices.
*/
- if (hdev->product == 0x0401 &&
- strncmp(hdev->name, "ELAN0800", 8) != 0)
- return true;
- /* Same with product id 0x0400 */
- if (hdev->product == 0x0400 &&
- strncmp(hdev->name, "QTEC0001", 8) != 0)
- return true;
+ if ((hdev->product == 0x0401 || hdev->product == 0x0400))
+ for (i = 0; strlen(elan_acpi_id[i].id); ++i)
+ if (!strncmp(hdev->name, elan_acpi_id[i].id,
+ strlen(elan_acpi_id[i].id)))
+ return true;
break;
}
--
2.17.1
^ permalink raw reply related
* Re: [dpdk-dev] [PATCH] maintainers: update dpdk-next-net-intel
From: Ferruh Yigit @ 2019-06-20 14:35 UTC (permalink / raw)
To: Qi Zhang, thomas; +Cc: beilei.xing, xiaolong.ye, dev
In-Reply-To: <20190619082412.31839-1-qi.z.zhang@intel.com>
On 6/19/2019 9:24 AM, Qi Zhang wrote:
> Xiaolong Ye will replace Beilei Xing as co-maintainer of
> dpdk-next-net-intel.
>
> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply
* Re: [PATCH] usb: core: devio: add ioctls for suspend and resume
From: Mayuresh Kulkarni @ 2019-06-20 14:34 UTC (permalink / raw)
To: Oliver Neukum, Alan Stern; +Cc: Greg KH, patches, linux-usb
In-Reply-To: <1560935981.4587.10.camel@suse.com>
On Wed, 2019-06-19 at 11:19 +0200, Oliver Neukum wrote:
> Am Dienstag, den 18.06.2019, 11:50 -0400 schrieb Alan Stern:
> >
> > On Tue, 18 Jun 2019, Mayuresh Kulkarni wrote:
> >
> > >
> > > >
> > > > You're right that the program needs to know when the device is
> > > > about
> > > > to
> > > > be suspended. But waiting for an ioctl to return isn't a good
> > > > way
> > > > to do it; this needs to be a callback of some sort. That is,
> > > > the
> > > > kernel also needs to know when the program is ready for the
> > > > suspend.
> > > >
> > > > I don't know what is the best approach.
> > > This is becoming tricky now.
> > Yes. There probably are mechanisms already in use in other parts
> > of
> > the kernel that would be suitable here, but I don't know what they
> > are.
> > We could try asking some other people for advice.
> Waiting for an ioctl() is horrible. If you really want to do this
> poll() would be the obvious API. It is made for waiting for changes
> of states.
>
Understood and agreed.
> [..]
> >
> > The suspend callback is _not_ responsible for actually suspending
> > the
> > device; that is handled by the USB subsystem core.
> >
> > These ideas are indeed applicable to programs using usbfs. The
> > kernel
> Not fully. Usbfs has the same issue as FUSE here. Drivers are per
> interface but power management is per device. Hence every driver
> is in the block IO path for these issues. You cannot do block IO
> in user space. The best you can do is notify of state changes,
> but you cannot wait for them.
>
> >
> > needs to have a way to inform the program that the device is about
> > enter (or has just left) a low-power state, so that the program can
> > stop (or start) trying to communicate with the device. And the
> > kernel
> > needs to know when the program is ready for the state change.
> That has difficulties based in fundamental issues. We can let user
> space block power transitions. We can notify it. But we cannot
> block on it.
>
> It would be easiest to export the usb_autopm_* API to user space.
AFAIU, usb_autopm_* API operate on interface rather than on device.
Due to this, they are *indirectly* exposed by appropriate class drivers
to the user-space class drivers cater to. E.g.: USB audio class driver
calls usb_autopm_* APIs when user space calls pcm_open(playback_stream).
>
> Regards
> Oliver
>
^ permalink raw reply
* Re: [PATCH] ath11k: fix whitespace error
From: Kalle Valo @ 2019-06-20 14:35 UTC (permalink / raw)
To: John Crispin; +Cc: ath11k
In-Reply-To: <20190619113548.19312-1-john@phrozen.org>
John Crispin <john@phrozen.org> wrote:
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath11k-bringup branch of ath.git, thanks.
0cb7ee3d1a84 ath11k: fix whitespace error
--
https://patchwork.kernel.org/patch/11003931/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
^ permalink raw reply
* Re: [PATCH] Revert "drm/amd/display: Enable fast plane updates when state->allow_modeset = true"
From: Deucher, Alexander @ 2019-06-20 14:35 UTC (permalink / raw)
To: Francis, David, Kazlauskas, Nicholas,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: Wentland, Harry
In-Reply-To: <BN8PR12MB3217FE6149291E3A7D053139EFE40-h6+T2+wrnx1RCczRXbE7rwdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2780 bytes --]
Is there a bugzilla this fixes? If so, can you add a link?
Alex
________________________________
From: amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of Francis, David <David.Francis-5C7GfCeVMHo@public.gmane.org>
Sent: Thursday, June 20, 2019 9:43 AM
To: Kazlauskas, Nicholas; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: Wentland, Harry
Subject: Re: [PATCH] Revert "drm/amd/display: Enable fast plane updates when state->allow_modeset = true"
Reviewed-by: David Francis <david.francis-5C7GfCeVMHo@public.gmane.org>
________________________________
From: amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of Nicholas Kazlauskas <nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
Sent: June 20, 2019 8:34:03 AM
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: Francis, David; Wentland, Harry; Kazlauskas, Nicholas
Subject: [PATCH] Revert "drm/amd/display: Enable fast plane updates when state->allow_modeset = true"
This reverts commit ebc8c6f18322ad54275997a888ca1731d74b711f.
There are still missing corner cases with cursor interaction and these
fast plane updates on Picasso and Raven2 leading to endless PSTATE
warnings for typical desktop usage depending on the userspace.
This change should be reverted until these issues have been resolved.
Cc: David Francis <david.francis-5C7GfCeVMHo@public.gmane.org>
Cc: Harry Wentland <harry.wentland-5C7GfCeVMHo@public.gmane.org>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas-5C7GfCeVMHo@public.gmane.org>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 33dcd4187157..d6acbcfa570c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6471,6 +6471,14 @@ static bool should_reset_plane(struct drm_atomic_state *state,
struct drm_crtc_state *new_crtc_state;
int i;
+ /*
+ * TODO: Remove this hack once the checks below are sufficient
+ * enough to determine when we need to reset all the planes on
+ * the stream.
+ */
+ if (state->allow_modeset)
+ return true;
+
/* Exit early if we know that we're adding or removing the plane. */
if (old_plane_state->crtc != new_plane_state->crtc)
return true;
--
2.17.1
_______________________________________________
amd-gfx mailing list
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[-- Attachment #1.2: Type: text/html, Size: 5272 bytes --]
[-- Attachment #2: Type: text/plain, Size: 153 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Re: [PATCH 4/4] restore: add --intent-to-add (restoring worktree only)
From: Derrick Stolee @ 2019-06-20 14:34 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20190620095523.10003-5-pclouds@gmail.com>
On 6/20/2019 5:55 AM, Nguyễn Thái Ngọc Duy wrote:
> "git restore --source" (without --staged) could create new files
> (i.e. not present in index) on worktree to match the given source. But
> the new files are not tracked, so both "git diff" and "git diff
> <source>" ignore new files. "git commit -a" will not recreate a commit
> exactly as the given source either.
>
> Add --intent-to-add to help track new files in this case, which is the
> default on the least surprise principle.
I was unfamiliar with this behavior, but did check the 'restore' command
myself and saw that it would register the file as untracked. I agree that
could be confusing for a user, so adding it to the staging environment
makes this more in-line with `git checkout <rev> -- <path>`.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Documentation/git-restore.txt | 7 ++++
> builtin/checkout.c | 78 +++++++++++++++++++++++++++++++++++
> t/t2070-restore.sh | 17 ++++++++
> 3 files changed, 102 insertions(+)
>
> diff --git a/Documentation/git-restore.txt b/Documentation/git-restore.txt
> index d90093f195..43a7f43b2b 100644
> --- a/Documentation/git-restore.txt
> +++ b/Documentation/git-restore.txt
> @@ -93,6 +93,13 @@ in linkgit:git-checkout[1] for details.
> are "merge" (default) and "diff3" (in addition to what is
> shown by "merge" style, shows the original contents).
>
> +--intent-to-add::
> +--no-intent-to-add::
> + When restoring files only on working tree with `--source`,
> + new files are marked as "intent to add" (see
> + linkgit:git-add[1]). This is the default behavior. Use
> + `--no-intent-to-add` to disable it.
> +
> --ignore-unmerged::
> When restoring files on the working tree from the index, do
> not abort the operation if there are unmerged entries and
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index f884d27f1f..c519067d3d 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -70,6 +70,7 @@ struct checkout_opts {
> int checkout_worktree;
> const char *ignore_unmerged_opt;
> int ignore_unmerged;
> + int intent_to_add;
>
> const char *new_branch;
> const char *new_branch_force;
> @@ -392,6 +393,69 @@ static int checkout_worktree(const struct checkout_opts *opts)
> return errs;
> }
>
> +/*
> + * Input condition: r->index contains the file list matching worktree.
> + *
> + * r->index is reloaded with $GIT_DIR/index. Files that exist in the
> + * current worktree but not in $GIT_DIR/index are added back as
> + * intent-to-add.
> + */
Reading this code (and being unfamiliar with the cache array) I thought
it might accidentally add untracked files from the working directory into
the index. A local test verified that was not the case. Is that worth
adding to your test below?
> +test_expect_success 'restore worktree only adds new files back as intent-to-add' '
> + git init ita &&
> + (
> + cd ita &&
> + test_commit one &&
> + test_commit two &&
> + git rm one.t &&
> + git commit -m one-is-gone &&
+ touch garbage &&
> + git restore --source one one.t &&
> + git diff --summary >actual &&
> + echo " create mode 100644 one.t" >expected &&
> + test_cmp expected actual &&
> + git diff --cached >empty &&
> + test_must_be_empty empty
> + )
> +'
> +
> test_done
Perhaps the line I inserted above would suffice to add this extra check?
Outside of that extra test (which may not be necessary), this series makes
sense to me.
Thanks,
-Stolee
^ permalink raw reply
* Re: [RFC 0/2] MIPS: fix code relocation routine
From: Sascha Hauer @ 2019-06-20 14:34 UTC (permalink / raw)
To: Antony Pavlov; +Cc: barebox, Oleksij Rempel
In-Reply-To: <20190618093833.2005-1-antonynpavlov@gmail.com>
On Tue, Jun 18, 2019 at 12:38:31PM +0300, Antony Pavlov wrote:
> At the moment MIPS relocation code routine has at least two problems:
>
> 1. the first problem is fixed in the 'MIPS: relocate_code: fix barebox image size'
> patch from this patchseries.
>
> 2. relocate_code() calls flush_cache_all().
> flush_cache_all() uses 'struct cpuinfo_mips current_cpu_data' data fields.
> These data fields are initialized in r4k_cache_init().
>
> However in the current implementation the r4k_cache_init() function
> is called __AFTER__ relocate_code().
>
> This cache problem can't be discovered via qemu.
>
> Antony Pavlov (2):
> MIPS: lib/Makefile: fix whitespaces
> MIPS: relocate_code: fix barebox image memcpy() size
Applied, thanks
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH] ath11k: Disable peer fixed before setting ht-mcs or vht-mcs
From: Kalle Valo @ 2019-06-20 14:33 UTC (permalink / raw)
To: Maharaja Kennadyrajan; +Cc: ath11k
In-Reply-To: <1560927014-17823-1-git-send-email-mkenna@codeaurora.org>
Maharaja Kennadyrajan <mkenna@codeaurora.org> wrote:
> Peer fixed rate should be disabled before setting the ht-mcs
> or vht-mcs as peer fixed rate has higher priority in the rate
> setting.
>
> Signed-off-by: Maharaja Kennadyrajan <mkenna@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath11k-bringup branch of ath.git, thanks.
a9e6c87cff1e ath11k: Disable peer fixed before setting ht-mcs or vht-mcs
--
https://patchwork.kernel.org/patch/11003535/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
^ permalink raw reply
* Re: [PATCH] perf/rapl: restart perf rapl counter after resume
From: Liang, Kan @ 2019-06-20 14:33 UTC (permalink / raw)
To: Peter Zijlstra, Zhang Rui
Cc: linux-x86, LKML, mingo, acme, alexander.shishkin, jolsa, namhyung,
tglx, Liang, Kan
In-Reply-To: <20190620125059.GZ3436@hirez.programming.kicks-ass.net>
On 6/20/2019 8:50 AM, Peter Zijlstra wrote:
> On Mon, Jun 17, 2019 at 09:41:37PM +0800, Zhang Rui wrote:
>
>> After S3 suspend/resume, "perf stat -I 1000 -e power/energy-pkg/ -a"
>> reports an insane value for the very first sampling period after resume
>> as shown below.
>>
>> 19.278989977 2.16 Joules power/energy-pkg/
>> 20.279373569 1.96 Joules power/energy-pkg/
>> 21.279765481 2.09 Joules power/energy-pkg/
>> 22.280305420 2.10 Joules power/energy-pkg/
>> 25.504782277 4,294,966,686.01 Joules power/energy-pkg/
>> 26.505114993 3.58 Joules power/energy-pkg/
>> 27.505471758 1.66 Joules power/energy-pkg/
>>
>> Fix this by resetting the counter right after resume.
>
> Cute...
>
>
>> +#ifdef CONFIG_PM
>> +
>> +static int perf_rapl_suspend(void)
>> +{
>> + int i;
>> +
>> + get_online_cpus();
>> + for (i = 0; i < rapl_pmus->maxpkg; i++)
>> + rapl_pmu_update_all(rapl_pmus->pmus[i]);
>> + put_online_cpus();
>> + return 0;
>> +}
>> +
>> +static void perf_rapl_resume(void)
>> +{
>> + int i;
>> +
>> + get_online_cpus();
>> + for (i = 0; i < rapl_pmus->maxpkg; i++)
>> + rapl_pmu_restart_all(rapl_pmus->pmus[i]);
>> + put_online_cpus();
>> +}
>
> What's the reason for that get/put_online_cpus() here ?
>
It looks like syscore_* functions are executed with one CPU on-line.
If so, they may not be the right place for the rapl callback.
Rapl is per socket. The driver manipulates the registers on the first
CPU of each socket. I think we need to update/restart the counters on
all sockets. That's the reason I add get/put_online_cpus() in the
original patch.
Besides, I think we also need to call rapl_pmu_restart/update_all() on
the target cpu.
Thanks,
Kan
^ permalink raw reply
* [PATCH v7 1/5] Input: elan_i2c: Export the device id whitelist
From: Jeffrey Hugo @ 2019-06-20 14:33 UTC (permalink / raw)
To: benjamin.tissoires, dmitry.torokhov, jikos, hdegoede
Cc: bjorn.andersson, agross, lee.jones, xnox, robh+dt, mark.rutland,
linux-input, devicetree, linux-arm-msm, linux-kernel,
Jeffrey Hugo
In-Reply-To: <20190620142801.11827-1-jeffrey.l.hugo@gmail.com>
Elan_i2c and hid-quirks work in conjunction to decide which devices each
driver will handle. Elan_i2c has a whitelist of devices that should be
consumed by hid-quirks so that there is one master list of devices to
handoff between the drivers. Put the ids in a header file so that
hid-quirks can consume it instead of duplicating the list.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
---
drivers/input/mouse/elan_i2c_core.c | 54 +----------------------
include/linux/input/elan-i2c-ids.h | 68 +++++++++++++++++++++++++++++
2 files changed, 69 insertions(+), 53 deletions(-)
create mode 100644 include/linux/input/elan-i2c-ids.h
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index 65cd325eabc3..74585712e979 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -37,6 +37,7 @@
#include <linux/completion.h>
#include <linux/of.h>
#include <linux/property.h>
+#include <linux/input/elan-i2c-ids.h>
#include <linux/regulator/consumer.h>
#include <asm/unaligned.h>
@@ -1375,63 +1376,10 @@ static const struct i2c_device_id elan_id[] = {
MODULE_DEVICE_TABLE(i2c, elan_id);
#ifdef CONFIG_ACPI
-static const struct acpi_device_id elan_acpi_id[] = {
- { "ELAN0000", 0 },
- { "ELAN0100", 0 },
- { "ELAN0600", 0 },
- { "ELAN0601", 0 },
- { "ELAN0602", 0 },
- { "ELAN0603", 0 },
- { "ELAN0604", 0 },
- { "ELAN0605", 0 },
- { "ELAN0606", 0 },
- { "ELAN0607", 0 },
- { "ELAN0608", 0 },
- { "ELAN0609", 0 },
- { "ELAN060B", 0 },
- { "ELAN060C", 0 },
- { "ELAN060F", 0 },
- { "ELAN0610", 0 },
- { "ELAN0611", 0 },
- { "ELAN0612", 0 },
- { "ELAN0615", 0 },
- { "ELAN0616", 0 },
- { "ELAN0617", 0 },
- { "ELAN0618", 0 },
- { "ELAN0619", 0 },
- { "ELAN061A", 0 },
- { "ELAN061B", 0 },
- { "ELAN061C", 0 },
- { "ELAN061D", 0 },
- { "ELAN061E", 0 },
- { "ELAN061F", 0 },
- { "ELAN0620", 0 },
- { "ELAN0621", 0 },
- { "ELAN0622", 0 },
- { "ELAN0623", 0 },
- { "ELAN0624", 0 },
- { "ELAN0625", 0 },
- { "ELAN0626", 0 },
- { "ELAN0627", 0 },
- { "ELAN0628", 0 },
- { "ELAN0629", 0 },
- { "ELAN062A", 0 },
- { "ELAN062B", 0 },
- { "ELAN062C", 0 },
- { "ELAN062D", 0 },
- { "ELAN0631", 0 },
- { "ELAN0632", 0 },
- { "ELAN1000", 0 },
- { }
-};
MODULE_DEVICE_TABLE(acpi, elan_acpi_id);
#endif
#ifdef CONFIG_OF
-static const struct of_device_id elan_of_match[] = {
- { .compatible = "elan,ekth3000" },
- { /* sentinel */ }
-};
MODULE_DEVICE_TABLE(of, elan_of_match);
#endif
diff --git a/include/linux/input/elan-i2c-ids.h b/include/linux/input/elan-i2c-ids.h
new file mode 100644
index 000000000000..8130bbebbdda
--- /dev/null
+++ b/include/linux/input/elan-i2c-ids.h
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Elan I2C Touchpad devide whitelist
+ *
+ * Copyright (C) 2019 Jeffrey Hugo. All rights reserved.
+ */
+
+#ifndef __ELAN_I2C_IDS_H
+#define __ELAN_I2C_IDS_H
+
+#include <linux/mod_devicetable.h>
+
+static const struct acpi_device_id elan_acpi_id[] = {
+ { "ELAN0000", 0 },
+ { "ELAN0100", 0 },
+ { "ELAN0600", 0 },
+ { "ELAN0601", 0 },
+ { "ELAN0602", 0 },
+ { "ELAN0603", 0 },
+ { "ELAN0604", 0 },
+ { "ELAN0605", 0 },
+ { "ELAN0606", 0 },
+ { "ELAN0607", 0 },
+ { "ELAN0608", 0 },
+ { "ELAN0609", 0 },
+ { "ELAN060B", 0 },
+ { "ELAN060C", 0 },
+ { "ELAN060F", 0 },
+ { "ELAN0610", 0 },
+ { "ELAN0611", 0 },
+ { "ELAN0612", 0 },
+ { "ELAN0615", 0 },
+ { "ELAN0616", 0 },
+ { "ELAN0617", 0 },
+ { "ELAN0618", 0 },
+ { "ELAN0619", 0 },
+ { "ELAN061A", 0 },
+ { "ELAN061B", 0 },
+ { "ELAN061C", 0 },
+ { "ELAN061D", 0 },
+ { "ELAN061E", 0 },
+ { "ELAN061F", 0 },
+ { "ELAN0620", 0 },
+ { "ELAN0621", 0 },
+ { "ELAN0622", 0 },
+ { "ELAN0623", 0 },
+ { "ELAN0624", 0 },
+ { "ELAN0625", 0 },
+ { "ELAN0626", 0 },
+ { "ELAN0627", 0 },
+ { "ELAN0628", 0 },
+ { "ELAN0629", 0 },
+ { "ELAN062A", 0 },
+ { "ELAN062B", 0 },
+ { "ELAN062C", 0 },
+ { "ELAN062D", 0 },
+ { "ELAN0631", 0 },
+ { "ELAN0632", 0 },
+ { "ELAN1000", 0 },
+ { }
+};
+
+static const struct of_device_id elan_of_match[] = {
+ { .compatible = "elan,ekth3000" },
+ { /* sentinel */ }
+};
+
+#endif /* __ELAN_I2C_IDS_H */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH V2] ath11k: fix mac_cap_info copy size
From: Kalle Valo @ 2019-06-20 14:33 UTC (permalink / raw)
To: John Crispin; +Cc: ath11k
In-Reply-To: <20190619061248.28891-1-john@phrozen.org>
John Crispin <john@phrozen.org> wrote:
> The code currently copies the he_cap field when adding a peer from a six
> byte to an eight byte buffer. Switch from using the dest buffer length to
> that of the src buffer. Also make sure that the trailing 2 bytes are
> zero'ed out.
>
> Signed-off-by: John Crispin <john@phrozen.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath11k-bringup branch of ath.git, thanks.
c7fda8adf751 ath11k: fix mac_cap_info copy size
--
https://patchwork.kernel.org/patch/11003513/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
^ permalink raw reply
* Re: [PATCH LOCAL] arm64: dts: renesas: r8a774a1: Remove dummy board DTS
From: Geert Uytterhoeven @ 2019-06-20 14:32 UTC (permalink / raw)
To: Chris Paterson
Cc: Simon Horman, Magnus Damm, Geert Uytterhoeven, Linux-Renesas
In-Reply-To: <20190620142325.28806-1-chris.paterson2@renesas.com>
On Thu, Jun 20, 2019 at 4:23 PM Chris Paterson
<chris.paterson2@renesas.com> wrote:
> This dummy dts file is no longer required as we have a real board, the
> r8a774a1-hihope-rzg2m.
>
> Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V6 06/27] PCI: tegra: Add PCIe Gen2 link speed support
From: Lorenzo Pieralisi @ 2019-06-20 14:32 UTC (permalink / raw)
To: Manikanta Maddireddy
Cc: thierry.reding, bhelgaas, robh+dt, mark.rutland, jonathanh,
vidyas, linux-tegra, linux-pci, devicetree
In-Reply-To: <20190618180206.4908-7-mmaddireddy@nvidia.com>
On Tue, Jun 18, 2019 at 11:31:45PM +0530, Manikanta Maddireddy wrote:
> Tegra124, Tegra132, Tegra210 and Tegra186 support Gen2 link speed. After
> PCIe link is up in Gen1, set target link speed as Gen2 and retrain link.
> Link switches to Gen2 speed if Gen2 capable end point is connected, else
> link stays in Gen1.
>
> Per PCIe 4.0r0.9 sec 7.6.3.7 implementation note, driver need to wait for
> PCIe LTSSM to come back from recovery before retraining the link.
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> Acked-by: Thierry Reding <treding@nvidia.com>
> ---
> V6: No change
>
> V5: No change
>
> V4: No change
>
> V3: Added blank line after each while loop.
>
> V2: Changed "for loop" to "while", to make it compact and handled coding
> style comments.
>
> drivers/pci/controller/pci-tegra.c | 64 ++++++++++++++++++++++++++++++
> 1 file changed, 64 insertions(+)
>
> diff --git a/drivers/pci/controller/pci-tegra.c b/drivers/pci/controller/pci-tegra.c
> index 5e9fcef5f8eb..5d19067f7193 100644
> --- a/drivers/pci/controller/pci-tegra.c
> +++ b/drivers/pci/controller/pci-tegra.c
> @@ -191,6 +191,8 @@
> #define RP_LINK_CONTROL_STATUS_DL_LINK_ACTIVE 0x20000000
> #define RP_LINK_CONTROL_STATUS_LINKSTAT_MASK 0x3fff0000
>
> +#define RP_LINK_CONTROL_STATUS_2 0x000000b0
> +
> #define PADS_CTL_SEL 0x0000009c
>
> #define PADS_CTL 0x000000a0
> @@ -226,6 +228,7 @@
> #define PADS_REFCLK_CFG_DRVI_SHIFT 12 /* 15:12 */
>
> #define PME_ACK_TIMEOUT 10000
> +#define LINK_RETRAIN_TIMEOUT 100000 /* in usec */
>
> struct tegra_msi {
> struct msi_controller chip;
> @@ -2089,6 +2092,64 @@ static bool tegra_pcie_port_check_link(struct tegra_pcie_port *port)
> return false;
> }
>
> +static void tegra_pcie_change_link_speed(struct tegra_pcie *pcie)
> +{
> + struct device *dev = pcie->dev;
> + struct tegra_pcie_port *port, *tmp;
> + ktime_t deadline;
> + u32 value;
> +
> + list_for_each_entry_safe(port, tmp, &pcie->ports, list) {
And the reason to use the _safe version is ?
Lorenzo
> + /*
> + * "Supported Link Speeds Vector" in "Link Capabilities 2"
> + * is not supported by Tegra. tegra_pcie_change_link_speed()
> + * is called only for Tegra chips which support Gen2.
> + * So there no harm if supported link speed is not verified.
> + */
> + value = readl(port->base + RP_LINK_CONTROL_STATUS_2);
> + value &= ~PCI_EXP_LNKSTA_CLS;
> + value |= PCI_EXP_LNKSTA_CLS_5_0GB;
> + writel(value, port->base + RP_LINK_CONTROL_STATUS_2);
> +
> + /*
> + * Poll until link comes back from recovery to avoid race
> + * condition.
> + */
> + deadline = ktime_add_us(ktime_get(), LINK_RETRAIN_TIMEOUT);
> +
> + while (ktime_before(ktime_get(), deadline)) {
> + value = readl(port->base + RP_LINK_CONTROL_STATUS);
> + if ((value & PCI_EXP_LNKSTA_LT) == 0)
> + break;
> +
> + usleep_range(2000, 3000);
> + }
> +
> + if (value & PCI_EXP_LNKSTA_LT)
> + dev_warn(dev, "PCIe port %u link is in recovery\n",
> + port->index);
> +
> + /* Retrain the link */
> + value = readl(port->base + RP_LINK_CONTROL_STATUS);
> + value |= PCI_EXP_LNKCTL_RL;
> + writel(value, port->base + RP_LINK_CONTROL_STATUS);
> +
> + deadline = ktime_add_us(ktime_get(), LINK_RETRAIN_TIMEOUT);
> +
> + while (ktime_before(ktime_get(), deadline)) {
> + value = readl(port->base + RP_LINK_CONTROL_STATUS);
> + if ((value & PCI_EXP_LNKSTA_LT) == 0)
> + break;
> +
> + usleep_range(2000, 3000);
> + }
> +
> + if (value & PCI_EXP_LNKSTA_LT)
> + dev_err(dev, "failed to retrain link of port %u\n",
> + port->index);
> + }
> +}
> +
> static void tegra_pcie_enable_ports(struct tegra_pcie *pcie)
> {
> struct device *dev = pcie->dev;
> @@ -2113,6 +2174,9 @@ static void tegra_pcie_enable_ports(struct tegra_pcie *pcie)
> tegra_pcie_port_disable(port);
> tegra_pcie_port_free(port);
> }
> +
> + if (pcie->soc->has_gen2)
> + tegra_pcie_change_link_speed(pcie);
> }
>
> static void tegra_pcie_disable_ports(struct tegra_pcie *pcie)
> --
> 2.17.1
>
^ permalink raw reply
* specifying revision - how to enforce matching a tag/branch-name or revision only
From: Boettger, Heiko @ 2019-06-20 14:32 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
I discovered an interesting problem when using `git checkout` to which I couldn't find a good solution. We have an automatic system trying to checkout a branch only when it exists. To do so we check whether `git rev-parse` finds a commit for given branch name:
git rev-parse "${BRANCH_NAME}" || git rev-parse "refs/remotes/${UPSTREAM}/${BRANCH_NAME}"
Unfortunately somebody used the branch name "add-gcc10" and `git rev-parse` which didn't exist on one repository. However `git rev-parse`
also supports to parse the `git-describe` format which resulted in checkout a commit starting with "cc10".
We saw a similar problem with disambiguation of tag and branch-name. If there any possibility to enforce that `git checkout` and other commands such `git rev-parse` handle a revision as a specific type (branch, tag, commit-id). Is there something like
`git checkout name@{branch}` or `git checkout name@{tag}` similar to other rev-parse format such as `branch@{upstream}`.
Best Regards
Heiko Böttger
^ permalink raw reply
* Re: [PATCH v1 00/12] ARM: stm32mp: add drivers for GPIO, pinctrl
From: Sascha Hauer @ 2019-06-20 14:32 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox
In-Reply-To: <20190617150751.3421-1-a.fatoum@pengutronix.de>
On Mon, Jun 17, 2019 at 05:07:39PM +0200, Ahmad Fatoum wrote:
> Feedback welcome.
>
> I still have a patch that ports designware_qos from U-Boot to barebox
> sitting on my branch. It works fine, but it needs refactoring, so it
> can reuse existing functionality in the generic designware MAC driver
> that's already in barebox. That will take a while, but if there's interest
> in it, I can push the current state somwhere till then.
>
> Cheers,
> Ahmad Fatoum (12):
> ARM: dts: stm32mp157a-dk1.dts: include upstream dts before barebox'
> ARM: dts: stm32mp: factor out common DK nodes into dtsi
> gpiolib: add gpio_get_chip helper
> driver: add stubs for hardware spinlocks
> pinctrl: add driver for STM32 GPIO and pin multiplexer
> ARM: dts: stm32mp157a-dk1: enable heartbeat and error LEDs
> ARM: stm32mp: turn on GPIO related options
> ARM: stm32mp157c-dk2: add board-specific sysconf fixups
> ARM: psci: fix erroneous call of ->system_reset on system_off
> ARM: sm: move get_gicd_base_address to header for reuse
> ARM: stm32mp: implement PSCI support
> ARM: stm32mp157c-dk2: boot kernel in nonsecure mode
Applied, thanks
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [Buildroot] [PATCH 0/3] Update Busybox to 1.31 and use mdev daemon mode
From: Thomas Petazzoni @ 2019-06-20 14:31 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20190619164257.183607-1-titouan.christophe@railnova.eu>
On Wed, 19 Jun 2019 18:42:54 +0200
Titouan Christophe <titouan.christophe@railnova.eu> wrote:
> Titouan Christophe (3):
> package/busybox: bump version to 1.31.0
> package/busybox: convert S10mdev to the canonical init script format
> package/busybox: run mdev in daemon mode
Series applied. Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* ✗ patchtest: failure for cmake.bbclass: pass mandatory compiler flags through CMAKE_<LANG>_COMPILER_ARG1 (rev2)
From: Patchwork @ 2019-06-20 14:30 UTC (permalink / raw)
To: Andrii Bordunov via Openembedded-core; +Cc: openembedded-core
In-Reply-To: <20190514150416.10902-1-n.merinov@inango-systems.com>
== Series Details ==
Series: cmake.bbclass: pass mandatory compiler flags through CMAKE_<LANG>_COMPILER_ARG1 (rev2)
Revision: 2
URL : https://patchwork.openembedded.org/series/17610/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:
* Patch [v2] cmake.bbclass: pass mandatory compiler flags through CMAKE_<LANG>_COMPILER_ARG1
Issue Patch is missing Signed-off-by [test_signed_off_by_presence]
Suggested fix Sign off the patch (either manually or with "git commit --amend -s")
If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).
---
Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
^ permalink raw reply
* Re: amdgpu vce crash
From: Deucher, Alexander @ 2019-06-20 14:30 UTC (permalink / raw)
To: CCXIAOP, amd-gfx
In-Reply-To: <tencent_969412320833AB29CB6FA2732FC516257905-9uewiaClKEY@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1302 bytes --]
If any of the engines hang, you can end up with a deadlock if you schedule dependencies across rings since one of the engines is hung. If you try a newer kernel, GPU reset is enabled and you should be able to recover after a hang. At that point, you can either restart your applications or use a relevant robustness API to properly handle a reset.
Alex
________________________________
From: amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of CCXIAOP <664296544-9uewiaClKEY@public.gmane.org>
Sent: Wednesday, June 19, 2019 5:28 AM
To: amd-gfx
Subject: amdgpu vce crash
We are using wx5100 for rendering and encoding operations, but sometimes we encounter vce timeout and crash.
Is vce not a independent module in gpu?Why does it affect the rendering module?
We hope that vce will not affect the rendering module when crashing.
Can I prevent the use of the rendering module from being affected?
linux kernel :4.19.34
mesa: 18.3.5
llvm: 7.0
firmware:18.50
As logs：
2019-06-15T15:33:32.133842+08:00|err|kernel[-]|[315248.172603] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring vce0 timeout, signaled seq=1173730, emitted seq=1173732
2019-06-15T15:33:32.133939+08:00|info|kernel[-]|[315248.172607] [drm] GPU recovery disabled.
[-- Attachment #1.2: Type: text/html, Size: 2305 bytes --]
[-- Attachment #2: Type: text/plain, Size: 153 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH v4 0/3] livepatch: Cleanup of reliable stacktrace warnings
From: Petr Mladek @ 2019-06-20 14:30 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Miroslav Benes, jikos, joe.lawrence, kamalesh, live-patching,
linux-kernel, Thomas Gleixner
In-Reply-To: <20190615204320.i4qxbk2m3ee73vyg@treble>
On Sat 2019-06-15 15:43:20, Josh Poimboeuf wrote:
> On Tue, Jun 11, 2019 at 04:13:17PM +0200, Miroslav Benes wrote:
> > This is the fourth attempt to improve the situation of reliable stack
> > trace warnings in livepatch. Based on discussion in
> > 20190531074147.27616-1-pmladek@suse.com (v3).
> >
> > Changes against v3:
> > + weak save_stack_trace_tsk_reliable() removed, because it is not needed
> > anymore thanks to Thomas' recent improvements
> > + klp_have_reliable_stack() check reintroduced in klp_try_switch_task()
> >
> > Changes against v2:
> >
> > + Put back the patch removing WARN_ONCE in the weak
> > save_stack_trace_tsk_reliable(). It is related.
> > + Simplified patch removing the duplicate warning from klp_check_stack()
> > + Update commit message for 3rd patch [Josh]
> >
> > Miroslav Benes (2):
> > stacktrace: Remove weak version of save_stack_trace_tsk_reliable()
> > Revert "livepatch: Remove reliable stacktrace check in
> > klp_try_switch_task()"
> >
> > Petr Mladek (1):
> > livepatch: Remove duplicate warning about missing reliable stacktrace
> > support
> >
> > kernel/livepatch/transition.c | 8 +++++++-
> > kernel/stacktrace.c | 8 --------
> > 2 files changed, 7 insertions(+), 9 deletions(-)
>
> Thanks Miroslav for wrapping this up, and thanks to Petr for his
> previous work on this.
>
> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
All three patches have been commited into for-5.3/core branch.
Best Regards,
Petr
^ permalink raw reply
* Hello
From: John M. @ 2019-06-20 14:30 UTC (permalink / raw)
To: linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw
Good Day.
I know reading my email, will be surprising to you and your
entire family, but please take whatever I am about to share with
you today seriously.
My name is John Mobutu, I am 22 years old, from Congo, my parents
were assassinated by opposition leaders many years ago, but thank
God the United Nations Peace Keeping, who came to rescue me and
my younger sister to Kenya, where we have been living presently.
My late father was into Gold and Diamond mining, while my late
mother was a Government worker.
My four consignment boxes containing 182 Million USD and 2,300
kilogram of gold was ship to the United Sates of America, three
weeks ago for delivery to Mr. Barry Miller, in Atlanta Ga, by
the United Nations Head Office in Africa, which is in Kenya, but
up till now the agents haven't been able to reach my beneficiary
and they are threatening to return my money and gold back to
Kenya, I am very disappointed and confuse right now, this is pure
evil.
Please I really need your assistance right now, if you are
willing to help us, kindly get back to us immediately for more
discussion.
Please kindly tell us more about yourself when replying to our
email. Thanks
God bless you
Sincerely
John
^ 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.