Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/touchscreen/resistive-adc-touch.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/touchscreen/raydium_i2c_ts.c | 30 +++---
1 file changed, 9 insertions(+), 21 deletions(-)
diff
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/touchscreen/elants_i2c.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/touchscreen/melfas_mip4.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/touchscreen/bu21013_ts.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/misc/pwm-vibra.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/touchscreen/bu21029_ts.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/keyboard/gpio_keys_polled.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/misc/pwm-beeper.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/mouse/elan_i2c_core.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/misc/gpio-vibra.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/keyboard/bcm-keypad.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git
Fixes IIO_VAL_FRACTIONAL for case when the result is negative and
exponent is 0.
example: if the result is -0.75, tmp0 will be 0 and tmp1 = 75
This causes the output to lose sign because of %d in snprintf
which works for tmp0 <= -1.
Signed-off-by: Anand Ashok Dumbre
---
changes since v1:
Hi Tom,
On 2019-12-21 15:03, Tom Murphy wrote:
This patchset converts the intel iommu driver to the dma-iommu api.
While converting the driver I exposed a bug in the intel i915 driver which
causes a huge amount of artifacts on the screen of my laptop. You can see a
picture of it here:
If you want to change this you'd need to change it over the whole
subsystem (if not other subsystems), including the places where the
value is used.
ok, I'll drop this patch for now, keep -ENOTSUPP and deal with this
later. The only thing I really care about for now is SoundWire MBQ
On 8/26/20 4:54 AM, Sakari Ailus wrote:
> Document the probe-low-power _DSD property and how it is used with I²C
> drivers.
>
> Signed-off-by: Sakari Ailus
> ---
> .../acpi/dsd/allow-low-power-probe.rst| 28 +++
> Documentation/firmware-guide/acpi/index.rst | 1 +
> 2
On Wed, Aug 26, 2020 at 2:30 AM Harald Arnesen wrote:
>
> Somehow related to lightdm or xfce4? However, it is a regression, since
> kernel 5.8 works.
Yeah, apparently there's something else wrong with the relocation changes too.
That said, does that patch at
On Wed, Aug 26, 2020 at 10:47 AM Thomas Gleixner wrote:
>
> Andy,
>
> On Wed, Aug 26 2020 at 09:13, Andy Lutomirski wrote:
> > On Wed, Aug 26, 2020 at 7:27 AM Thomas Gleixner wrote:
> >> The below nasty hack cures it, but I hate it with a passion. I'll look
> >> deeper for a sane variant.
> >>
>
On Wed, 26 Aug 2020 17:37:30 +0100,
Marc Zyngier wrote:
>
> Hi Valentin,
>
> On 2020-08-26 12:16, Valentin Schneider wrote:
> > Hi Marc,
> >
> > Many thanks for picking this up!
> > Below's the only comment I have, the rest LGTM.
> >
> > On 24/08/20 11:23, Marc Zyngier wrote:
> >>
Hi,
Driver looks mostly good.
On Sat, Aug 15, 2020 at 06:56:09PM +0200, Andreas Kemnade wrote:
> [...]
> +static int rn5t618_battery_current_now(struct rn5t618_power_info *info,
> +union power_supply_propval *val)
> +{
> + u16 res;
> + int ret;
> +
> +
Andy,
On Wed, Aug 26 2020 at 09:13, Andy Lutomirski wrote:
> On Wed, Aug 26, 2020 at 7:27 AM Thomas Gleixner wrote:
>> The below nasty hack cures it, but I hate it with a passion. I'll look
>> deeper for a sane variant.
>>
> Fundamentally, the way we overload orig_ax is problematic. I have a
>
Hi Leon, Shuah,
Thanks for the fix. I had this issue pending to fix,
but have been lazy about it, I appreciate you are taking care of it!
On Sat, 7 Mar 2020 at 11:03, Leon He wrote:
>
> From: Leon He
>
> There are two errors in the dmabuf-heap selftest:
> 1. The 'char name[5]' was not
On Wed, 2020-08-26 at 19:00 +0200, Rafael J. Wysocki wrote:
> On Wed, Aug 26, 2020 at 6:46 PM Guilhem Lettron
> wrote:
> >
> > I've done more tests, maybe it can give you more hints.
> > I don't see that much differences between both (with and without
> > patches) in this cases.
>
> OK, thanks!
On Wed, Aug 26, 2020 at 11:51:42AM -0400, Vivek Goyal wrote:
> On Wed, Aug 26, 2020 at 04:06:35PM +0200, Miklos Szeredi wrote:
> > On Thu, Aug 20, 2020 at 12:21 AM Vivek Goyal wrote:
> > >
> > > The device communicates FUSE_SETUPMAPPING/FUSE_REMOVMAPPING alignment
> > > constraints via the
On Tue, Aug 25, 2020 at 11:02:40PM -0400, Qian Cai wrote:
> On Aug 25, 2020, at 8:44 PM, Rong Chen wrote:
> > I rebuilt the kernel on commit c566586818 but the error changed to
> > "RIP: 0010:clear_page_orig+0x12/0x40", and the error can be
> > reproduced on parent commit:
>
> Catalin, any
On Wed 26-08-20 12:43:32, Johannes Weiner wrote:
> On Wed, Aug 26, 2020 at 09:47:02PM +0800, Xunlei Pang wrote:
> > We've met softlockup with "CONFIG_PREEMPT_NONE=y", when
> > the target memcg doesn't have any reclaimable memory.
> >
> > It can be easily reproduced as below:
> > watchdog: BUG:
On 8/12/20 9:46 AM, Sean V Kelley wrote:
From: Jonathan Cameron
Currently the kernel does not handle AER errors for Root Complex
integrated End Points (RCiEPs)[0]. These devices sit on a root bus within
the Root Complex (RC). AER handling is performed by a Root Complex Event
Collector
On Wed, Aug 26, 2020 at 10:05:50AM -0500, Pierre-Louis Bossart wrote:
> I assumed this change to -EOPNOTSUPP reflected a consensus in kernel-land,
> it's obviously not the case. This patch was supposed to be a trivial
> clean-up...
No, it's just some random guy sent a patch. They've not made
On 8/26/20 7:47 AM, Krzysztof Kozlowski wrote:
> Common pattern of handling deferred probe can be simplified with
> dev_err_probe(). Less code and also it prints the error value.
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Florian Fainelli
--
Florian
: u_f: add overflow checks to VLA macros
Sorry, but the above patch breaks USB Ethernet Gadget operation. It also
didn't get the proper testing in linux-next (next-20200826 is the first
one with this patch).
This is how it explodes on Samsung Exynos (ARM 32bit) based board with
g_ether module loaded
Hi Enric
On Wed, Aug 26, 2020 at 10:15:21AM +0200, Enric Balletbo i Serra wrote:
> The first patch was initially part of the series [1] but for some reason
> was not picked when the series were merged, so I included in this series
> because it is needed to make the others to work properly.
>
>
On Wed, Aug 26, 2020 at 6:43 AM Greg KH wrote:
>
> USB fixes for 5.9-rc3
I'm dropping this, since it seems to break things more than it fixes.
I see that the breakage is already figured out, but I'll just wait for
the next fixes pull with the fix for the problem.
Linus
On Wed, Aug 26, 2020 at 8:15 AM Jann Horn wrote:
>
> After this series has landed, we should be able to rip out
> mmget_still_valid().
I think you should just add that to the series, since it's kind of the
point of it all.
But ack on this, it now looks saner than what we used to have
For the CPU clock registration two parent clocks are required, these
are now being passed as struct clk_hw pointers, rather than by the
global scope names. That allows us to avoid __clk_lookup() calls
and simplifies a bit the CPU clock registration function.
While at it drop unneeded extern
Use non-zero clock IDs in definitions of the CPU parent clocks
for exynos5420, exynos5250 SoCs. This will allow us to reference
the parent clocks directly in the driver by cached struct clk_hw
pointers, rather than doing clk lookup by name.
Signed-off-by: Sylwester Nawrocki
---
Add clock ID definitions for the CPU parent clocks for SoCs
which don't have such definitions yet. This will allow us to
reference the parent clocks directly by cached struct clk_hw
pointers in the clock provider, rather than doing clk lookup
by name.
Signed-off-by: Sylwester Nawrocki
---
On Wed, Aug 26, 2020 at 8:15 AM Jann Horn wrote:
>
> A downside of this approach is that we now need a bigger amount of kernel
> memory per userspace VMA in the normal ELF case, and that we need O(n)
> kernel memory in the FDPIC ELF case at all; but 40 bytes per VMA shouldn't
> be terribly bad.
From: Cameron Nemo
RK3328 SoCs have one USB 3.0 OTG controller which uses DWC_USB3
core's general architecture. It can act as static xHCI host
controller, static device controller, USB 3.0/2.0 OTG basing
on ID of USB3.0 PHY.
Signed-off-by: William Wu
Signed-off-by: Heiko Stuebner
From: Cameron Nemo
Enable USB3 nodes for the rk3328-based PINE Rock64 board.
Signed-off-by: Heiko Stuebner
Signed-off-by: Cameron Nemo
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git
On Wed, 2020-08-26 at 10:05 +0300, Jani Nikula wrote:
> On Tue, 25 Aug 2020, Lyude Paul wrote:
> > And of course, we'll also need to read the sink count from other drivers
> > as well if we're checking whether or not it's supported. So, let's
> > extract the code for this into another helper.
> >
Sam Ravnborg 于2020年7月29日周三 上午4:27写道：
>
> Hi Kevin
>
> On Tue, Jul 28, 2020 at 06:07:54PM +0800, Kevin Tang wrote:
> > From: Kevin Tang
> >
> > The Unisoc DRM master device is a virtual device needed to list all
> > DPU devices or other display interface nodes that comprise the
> > graphics
On Wed, 2020-08-26 at 10:05 +0300, Jani Nikula wrote:
> On Tue, 25 Aug 2020, Lyude Paul wrote:
> > And of course, we'll also need to read the sink count from other drivers
> > as well if we're checking whether or not it's supported. So, let's
> > extract the code for this into another helper.
> >
On Wed, Aug 26, 2020 at 06:51:48PM +0200, Florian Weimer wrote:
> * Dave Martin:
>
> > On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote:
> >> On 8/25/2020 4:20 PM, Dave Hansen wrote:
> >> >On 8/25/20 2:04 PM, Yu, Yu-cheng wrote:
> >> I think this is more arch-specific. Even if it
On Wed, Aug 26, 2020 at 9:52 AM Florian Weimer wrote:
>
> * Dave Martin:
>
> > On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote:
> >> On 8/25/2020 4:20 PM, Dave Hansen wrote:
> >> >On 8/25/20 2:04 PM, Yu, Yu-cheng wrote:
> >> I think this is more arch-specific. Even if it becomes
On Wed, Aug 26, 2020 at 07:09:50PM +0300, Vladimir Oltean wrote:
> I don't even know if NXP0005 is made up or if it's written down
> somewhere in the PNP ID registry. NXP0006 seems to be assigned to the
Well, any ID is made up to some extent. I am concerned about the
allocation of IDs too, it
This patchset tests/demonstrates using dynamic_debug_exec_queries() to
alter 2 drivers' pr_debugs without a user directly using >control.
For drm.core, I copied drm.debug module parameter model, adding
drm.debug2 as a POC user interface to control 2 pr_debug additions to
The gvt component of this driver has ~120 pr_debugs, in 9 "classes".
Add a "knob", like drm.debug, to map bits to these classes.
bash-5.0# echo 0x01 > /sys/module/i915/parameters/debug_dyn
set_dyndbg: result:0x1 from 0x01
dyndbg: query 0: "format='^gvt: cmd: ' +p"
dyndbg: entry,
Export of dynamic-debug-exec-queries exists for users like drm.
This commit is a 1st user-test; it adds a 2nd knob, __drm_debug2,
similar in function to __drm_debug. module_param_cb wires it to a
callback which maps the input value to one of: "module=drm* +/-p".
The include is needed to see the
Put the pr_debug() after the vaf setup work, so as to use it. And
move the if-category-disabled-return after both, so the pr_debug()
runs unconditionally.
This lets both debug-printers execute independently, according to
their respective controls, allowing later comparison to each other.
#>
This addition to cflags enables dyndbg in the gvt component of the
i915 module, on a CONFIG_DYNAMIC_DEBUG_CORE build.
So here are the message classifications that the gvt driver uses.
cut -d= -f2 | cut -d\ -f2,3 | \
perl -ne 'chomp $_ && $h{$_}++; END{print "$_\" \tseen $h{$_}\n" for sort
The ptrace() test forgot to reap its child. Reap it.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/fsgsbase.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/testing/selftests/x86/fsgsbase.c
b/tools/testing/selftests/x86/fsgsbase.c
index
This tesst commit 8ab49526b53d ("x86/fsgsbase/64: Fix NULL deref in
86_fsgsbase_read_task"). Unpatched kernels will OOPS.
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/fsgsbase.c | 65 ++
1 file changed, 65 insertions(+)
diff
This fixes a minor bug and adds a test for the recent NULL pointer
dereference.
Andy Lutomirski (2):
selftests/x86/fsgsbase: Reap a forgotten child
selftests/x86/fsgsbase: Test PTRACE_PEEKUSER for GSBASE with invalid
LDT GS
tools/testing/selftests/x86/fsgsbase.c | 68
On Wed, Aug 26, 2020 at 6:46 PM Guilhem Lettron wrote:
>
> I've done more tests, maybe it can give you more hints.
> I don't see that much differences between both (with and without
> patches) in this cases.
OK, thanks!
I'm assuming that the topmost two sets of data are for the "without
the
On 8/26/20 11:33 AM, Vinod Koul wrote:
This series attempts to fix return check for devm_regmap_init_sdw()
Changes in v2:
- Add missing patch for rt711
- Add patch for rt700
Vinod Koul (5):
ASoC: max98373: Fix return check for devm_regmap_init_sdw()
ASoC: rt1308-sdw: Fix return
On Wed, Aug 26, 2020 at 05:20:29PM +0530, Viresh Kumar wrote:
> The bindings allow multiple versions to be passed to "opp-supported-hw"
> property, either of which can result in enabling of the OPP.
>
> Update code to allow that.
>
> Signed-off-by: Viresh Kumar
This is exactly what I was
On Wed, Aug 26, 2020 at 9:57 AM Joe Perches wrote:
>
> On Thu, 2020-08-27 at 01:49 +0900, Masahiro Yamada wrote:
> > I do not have time to keep track of the discussion fully,
> > but could you give me a little more context why
> > the usage of stpcpy() is not recommended ?
> >
> > The
On Thu, 2020-08-27 at 01:49 +0900, Masahiro Yamada wrote:
> I do not have time to keep track of the discussion fully,
> but could you give me a little more context why
> the usage of stpcpy() is not recommended ?
>
> The implementation of strcpy() is almost the same.
> It is unclear to me what
+#include
+#include
+#include
Curious why do you need this header?
I'll return the question back to you, since you added this header for
regmap-sdw.c:
7c22ce6e21840 (Vinod Koul 2018-01-08 15:50:59 +0530 6)
#include
so I assumed it was needed here as well.
On Wed, Aug 26, 2020 at 05:47:44PM +0300, Vladimir Oltean wrote:
> On Wed, Aug 26, 2020 at 03:23:12PM +0100, Mark Brown wrote:
> > On Wed, Aug 26, 2020 at 02:47:58PM +0300, Vladimir Oltean wrote:
> > > { "NXP0005", .driver_data = (kernel_ulong_t)_data[LS2085A], }
> > Based on some other stuff
allyesconfig
powerpc allmodconfig
i386 randconfig-a002-20200826
i386 randconfig-a004-20200826
i386 randconfig-a003-20200826
i386 randconfig-a005-20200826
i386 randconfig-a006-20200826
i386
On Fri, Aug 14, 2020 at 11:09 AM Dave Hansen wrote:
>
> On 8/14/20 10:46 AM, Andy Lutomirski wrote:
> > I'm a little unconvinced about the security benefits. As far as I
> > know, UC memory will not end up in cache by any means (unless
> > aliased), but it's going to be tough to do much with UC
On Wed, Aug 26, 2020 at 11:09:18PM +0800, Tang Bin wrote:
> The function fsl_spdif_probe() is only called with an openfirmware
> platform device. Therefore there is no need to check that the passed
> in device is NULL.
Why is this an issue - the check will make things more robust if someone
On Wed, 2020-08-26 at 18:43 +0200, Rafael J. Wysocki wrote:
> > I am curious, somehow that patch makes a difference.
>
> It does make a difference, because it makes the processor spend more
> time in PC2. Which very well may be because the processor cannot
> enter deeper C-states.
OK, you are
On 8/26/20 4:37 AM, Dan Carpenter wrote:
Callers are generally not supposed to check the return values from
debugfs functions. Debugfs functions never return NULL so this error
handling will never trigger. (Historically debugfs functions used to
return a mix of NULL and error pointers but it
On Wed, Aug 26, 2020 at 06:45:33PM +0200, Krzysztof Kozlowski wrote:
> On Wed, Aug 26, 2020 at 04:59:09PM +0200, Lukasz Stelmach wrote:
> >> +#include
> > >> +#endif
> > >> +#include
> > >> +#include
> > >> +#include
> > >> +#include
> > >> +#include
> > >> +#include
> > >> +#include
> >
* Dave Martin:
> On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote:
>> On 8/25/2020 4:20 PM, Dave Hansen wrote:
>> >On 8/25/20 2:04 PM, Yu, Yu-cheng wrote:
>> I think this is more arch-specific. Even if it becomes a new syscall,
>> we still need to pass the same parameters.
>>
Hi Thomas,
On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
From: Thomas Gleixner
None of the DMAR specific fields are required.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |6 --
arch/x86/kernel/apic/msi.c| 10 +-
2 files changed, 5
On Tue, Aug 25, 2020 at 10:58 PM Nick Desaulniers
wrote:
>
> LLVM implemented a recent "libcall optimization" that lowers calls to
> `sprintf(dest, "%s", str)` where the return value is used to
> `stpcpy(dest, str) - dest`. This generally avoids the machinery involved
> in parsing format strings.
Add a return value to function rproc_shutdown() in order to
properly deal with error conditions that may occur.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_core.c | 13 +
include/linux/remoteproc.h | 2 +-
2 files changed, 10 insertions(+), 5
Introduce function __rproc_detach() to perform the same kind of
operation as rproc_stop(), but instead of switching off the
remote processor using rproc->ops->stop(), it uses
rproc->ops->detach(). That way it is possible for the core
to release the resources associated with a remote processor
On Wed, Aug 26, 2020 at 04:59:09PM +0200, Lukasz Stelmach wrote:
> It was <2020-08-25 wto 20:44>, when Krzysztof Kozlowski wrote:
> > On Tue, Aug 25, 2020 at 07:03:09PM +0200, Łukasz Stelmach wrote:
> >> ASIX AX88796[1] is a versatile ethernet adapter chip, that can be
> >> connected to a CPU with
The state of the remote processor may have changed between the
time a call to rproc_shutdown() was made and the time it is
executed. To avoid moving forward with an operation that may
have been cancelled, recheck while holding the mutex.
Cc:
Signed-off-by: Mathieu Poirier
---
This patch introduces the capability to stop a remote processor
that has been attached to by the remoteproc core. For that to
happen a rproc::ops::stop() operation need to be available.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_cdev.c | 5 +++--
On 8/25/20 9:20 AM, Stefano Garzarella wrote:
> Hi Jens,
> this is a gentle ping.
>
> I'll respin, using memdup_user() for restriction registration.
> I'd like to get some feedback to see if I should change anything else.
>
> Do you think it's in good shape?
As far as I'm concerned, this is
The following commit has been merged into the ras/core branch of tip:
Commit-ID: 1e36d9c6886849c6f3d3c836370563e6bc1a6ddd
Gitweb:
https://git.kernel.org/tip/1e36d9c6886849c6f3d3c836370563e6bc1a6ddd
Author:Tony Luck
AuthorDate:Mon, 24 Aug 2020 15:12:37 -07:00
Committer:
On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote:
> On 8/25/2020 4:20 PM, Dave Hansen wrote:
> >On 8/25/20 2:04 PM, Yu, Yu-cheng wrote:
> I think this is more arch-specific. Even if it becomes a new syscall,
> we still need to pass the same parameters.
> >>>
> >>>Right, but
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
I've done more tests, maybe it can give you more hints.
I don't see that much differences between both (with and without
patches) in this cases.
--
Guilhem Lettron
CoreCPU Avg_MHz Busy% Bzy_MHz TSC_MHz IRQ SMI POLLC1_ACPI
C2_ACPI C3_ACPI POLL% C1_ACPI%C2_ACPI%
g |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200826.orig/drivers/gpu/drm/virtio/Kconfig
+++ linux-next-20200826/drivers/gpu/drm/virtio/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_VIRTIO_GPU
tristate "Virtio GPU dr
Align what was done for rproc_detach() by renaming function
rproc_actuate(). That way it is easier to figure out the
opposite of each functions.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_core.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
There is a need to know when a remote processor has been attached
to rather than booted by the remoteproc core. In order to avoid
manipulating two variables, i.e rproc::autonomous and
rproc::state, get rid of the former and simply use the newly
introduced RPROC_ATTACHED state.
Signed-off-by:
Introduce function rproc_detach() to enable the remoteproc
core to release the resources associated with a remote processor
without stopping its operation.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_core.c | 65 +++-
include/linux/remoteproc.h
Refactor function rproc_del() and rproc_cdev_release() to take
into account scenarios where the remote processor has been
attached to. If the remote processor has been started by the
remoteproc core then switch it off, and if it was attached to
detach from it. This heuristic is simple and can be
This patch introduces the capability to detach a remote processor
that has been attached to or booted by the remoteproc core. For
that to happen a rproc::ops::detach() operation need to be
available.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_cdev.c | 6 ++
Add an new detach() operation in order to support scenarios where
the remoteproc core is going away but the remote processor is
kept operating. This could be the case when the system is
rebooted or when the platform driver is removed.
Signed-off-by: Mathieu Poirier
---
Add a new RPROC_ATTACHED state to take into account scenarios
where the remoteproc core needs to attach to a remote processor
that is booted by another entity.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_sysfs.c | 1 +
include/linux/remoteproc.h| 7 +--
2
Whether started at probe() time or thereafter from the command
line, a remote processor needs to be shutdown before the final
cleanup phases can happen. Otherwise the system may be left in
an unpredictable state where the remote processor is expecting
the remoteproc core to be providing services
Following the work done here [1] this set provides support for the
remoteproc core to release resources associated with a remote processor
without having to switch it off. That way a platform driver can be removed
or the applcation processor power cycled while the remote processor is
still
On Wed, Aug 26, 2020 at 09:47:02PM +0800, Xunlei Pang wrote:
> We've met softlockup with "CONFIG_PREEMPT_NONE=y", when
> the target memcg doesn't have any reclaimable memory.
>
> It can be easily reproduced as below:
> watchdog: BUG: soft lockup - CPU#0 stuck for 111s![memcg_test:2204]
> CPU: 0
On Wed, Aug 26, 2020 at 5:54 PM Nicholas Piggin wrote:
>
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Albert Ou
> Cc: linux-ri...@lists.infradead.org
> Acked-by: Palmer Dabbelt
> Signed-off-by: Nicholas Piggin
Reviewed-by: Pekka Enberg
On Wed, Aug 26, 2020 at 6:39 PM Artem Bityutskiy wrote:
>
> On Wed, 2020-08-26 at 18:02 +0200, Rafael J. Wysocki wrote:
> > To that end, I would try to upgrade the graphics firmware and see if
> > you can get some nonzero PC8 residency then.
>
> I am curious, somehow that patch makes a
On Wed, Aug 26, 2020 at 6:19 PM Artem Bityutskiy wrote:
>
> Indeed, when I compare them:
>
> acpi_idle (without the patch):
Does this come from the Guilhem's data? It's intel_idle in both
cases, but in the "without the patch" case it uses ACPI.
> CPU%c1 CPU%c6 CPU%c7 CoreTmp PkgTmp GFX%rc6
On 26-08-20, 10:00, Pierre-Louis Bossart wrote:
>
>
> > > +/* v1.2 device - SDCA address mapping */
> >
> > Can you please add description of bits used by each field here,
> > something like we have done for DevId
>
> were you referring to something like this?
>
> * Spec definition
> *
Hi Satya,
On Wed, Aug 26, 2020 at 09:35:15PM +0530, ska...@codeaurora.org wrote:
> Hi Matthias,
>
> On 2020-08-25 22:08, Matthias Kaehlcke wrote:
> > On Tue, Aug 25, 2020 at 06:42:28PM +0530, ska...@codeaurora.org wrote:
> > > On 2020-08-21 22:52, Matthias Kaehlcke wrote:
> > > > On Thu, Aug 20,
On Wed, 2020-08-26 at 18:02 +0200, Rafael J. Wysocki wrote:
> To that end, I would try to upgrade the graphics firmware and see if
> you can get some nonzero PC8 residency then.
I am curious, somehow that patch makes a difference.
Guilhem, what do we actually compare: same kernel, just patched
Hi Valentin,
On 2020-08-26 12:16, Valentin Schneider wrote:
Hi Marc,
Many thanks for picking this up!
Below's the only comment I have, the rest LGTM.
On 24/08/20 11:23, Marc Zyngier wrote:
Signed-off-by: Marc Zyngier
---
drivers/bus/fsl-mc/fsl-mc-msi.c | 2 ++
1 file changed, 2
Hi YueHaibing,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux-nvdimm/libnvdimm-for-next]
[also build test ERROR on v5.9-rc2 next-20200826]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On Mon, 24 Aug 2020, 2:42pm, Alex Dewar wrote:
>
> On 2020-08-20 19:51, Alex Dewar wrote:
> > In qla25xx_set_els_cmds_supported(), a call is made to
> > dma_alloc_coherent() followed by zeroing the memory with memset. This is
> > unnecessary as dma_alloc_coherent() already zeros memory. Remove.
On 26.08.20 16:27, Thomas Gleixner wrote:
On Wed, Aug 26 2020 at 13:53, Alexander Graf wrote:
Commit 633260fa143 ("x86/irq: Convey vector as argument and not in ptregs")
changed the handover logic of the vector identifier from ~vector in orig_ax
to purely register based. Unfortunately, this
401 - 500 of 1479 matches
Mail list logo
