The patch
ASoC: tas2770: Fix snd_soc_update_bits error handling
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
ASoc: tas2770: Remove unused defines and variables
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
On Mon, Oct 7, 2019 at 10:34 AM Al Viro wrote:
>
> Tangentially related: copy_regster_to_user() and copy_regset_from_user().
Not a worry. It's not performance-critical code, and if it ever is, it
needs to be rewritten anyway.
> The former variant tends to lead to few calls
> of
On Mon, Oct 07, 2019 at 05:20:30PM +0100, Steven Price wrote:
> On 07/10/2019 17:10, Jason Gunthorpe wrote:
> > On Mon, Oct 07, 2019 at 04:38:14PM +0100, Steven Price wrote:
> >> diff --git a/mm/hmm.c b/mm/hmm.c
> >> index 902f5fa6bf93..34fe904dd417 100644
> >> +++ b/mm/hmm.c
> >> @@ -376,7 +376,7
On Mon, Oct 7, 2019 at 8:40 AM David Laight wrote:
>
> You don't really want an extra access_ok() for every 'word' of a copy.
Yes you do.
> Some copies have to be done a word at a time.
Completely immaterial. If you can't see the access_ok() close to the
__get/put_user(), you have a bug.
Plus
YueHaibing writes:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Signed-off-by: YueHaibing
Reviewed-by: Kevin Hilman
> ---
> drivers/rtc/rtc-meson.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git
On Mon, Oct 07, 2019 at 08:55:55PM +0300, Jarkko Sakkinen wrote:
> But checkpatch.pl will complain about it...
You should not take checkpatch.pl messages to the letter but always
sanity-check them with common sense. In this particular example,
readability is much more important than some tool
On Sat, Oct 5, 2019 at 9:46 AM Joe Perches wrote:
>
> fallthrough may become a pseudo reserved keyword so this only use of
> fallthrough is better renamed to allow it.
>
> Signed-off-by: Joe Perches
> ---
> net/sctp/sm_make_chunk.c | 12 ++--
> 1 file changed, 6 insertions(+), 6
Hi s390 maintainers,
This patch mirrors a similar patch for x86, but it has been untested
because I do not have a mainframe to compile on :)
In 5.4-rc1 the 2 different sha256 implementations for the purgatory resp.
for crypto/sha256_generic.c have been consolidated into 1 single shared
Since we link purgatory with -r aka we enable "incremental linking"
no checks for unresolved symbols are done while linking the purgatory.
This commit adds an extra check for unresolved symbols by calling ld
without -r before running objcopy to generate purgatory.ro.
This will help us catch
On Mon, 2019-10-07 at 17:27 +0200, Vincent Guittot wrote:
> On Mon, 7 Oct 2019 at 17:14, Rik van Riel wrote:
> > On Thu, 2019-09-19 at 09:33 +0200, Vincent Guittot wrote:
> > > runnable load has been introduced to take into account the case
> > > where
> > > blocked load biases the wake up path
Hi Moritz,
On 9/27/19 1:23 PM, Moritz Fischer wrote:
Thor,
On Fri, Sep 27, 2019 at 09:32:11AM -0500, Thor Thayer wrote:
Hi Kedar & Moritz,
On 9/27/19 12:13 AM, Appana Durga Kedareswara Rao wrote:
Hi Alan,
Did you get a chance to send your framework changes to upstream?
No they weren't
On 30.09.19 17:38, Halil Pasic wrote:
> Commit 37db8985b211 ("s390/cio: add basic protected virtualization
> support") breaks virtio-ccw devices with VIRTIO_F_IOMMU_PLATFORM for non
> Protected Virtualization (PV) guests. The problem is that the dma_mask
> of the ccw device, which is used by
On Mon, Oct 7, 2019 at 12:00 PM Andreas Klinger wrote:
>
> Hi Rob,
>
> i don't get this error. Is there anything i'm doing wrong here?
>
> ak@arbad:/project/opt-sw/linux-robh$ make O=../build-wega-robh/
> dt_binding_check
> make[1]: Verzeichnis „/project/opt-sw/build-wega-robh“ wird betreten
>
From: Kan Liang
Support new sample type PERF_SAMPLE_LBR_TOS.
Enable LBR_TOS by default in LBR call stack mode.
If kernel doesn't support the sample type, switching it off.
Reviewed-by: Andi Kleen
Signed-off-by: Kan Liang
---
tools/include/uapi/linux/perf_event.h | 4 +++-
From: Kan Liang
The PMU capabilities information, which is located at
/sys/bus/event_source/devices//caps, is required by perf tool.
For example, the max LBR information is required to stitch LBR call
stack.
Add perf_pmu__caps_parse() to parse the PMU capabilities information.
The information
From: Kan Liang
LBR only collect the user call stack. To reconstruct a call stack, both
kernel call stack and user call stack are required. The function
resolve_lbr_callchain_sample() mix the kernel call stack and user
call stack. Now, with the help of TOS, perf tool can reconstruct a more
From: Kan Liang
With the LBR stitching approach, the reconstructed LBR call stack
can break the HW limitation. However, it may reconstruct invalid call
stacks in some cases, e.g. exception handing such as setjmp/longjmp.
Also, it may impact the processing time especially when the number of
From: Kan Liang
With the LBR stitching approach, the reconstructed LBR call stack
can break the HW limitation. However, it may reconstruct invalid call
stacks in some cases, e.g. exception handing such as setjmp/longjmp.
Also, it may impact the processing time especially when the number of
From: Kan Liang
With the LBR stitching approach, the reconstructed LBR call stack
can break the HW limitation. However, it may reconstruct invalid call
stacks in some cases, e.g. exception handing such as setjmp/longjmp.
Also, it may impact the processing time especially when the number of
From: Kan Liang
With the LBR stitching approach, the reconstructed LBR call stack
can break the HW limitation. However, it may reconstruct invalid call
stacks in some cases, e.g. exception handing such as setjmp/longjmp.
Also, it may impact the processing time especially when the number of
From: Kan Liang
In LBR call stack mode, the depth of reconstructed LBR call stack limits
to the number of LBR registers. With LBR Top-of-Stack (TOS) information,
perf tool may stitch the stacks of two samples. The reconstructed LBR
call stack can break the HW limitation.
Add a new sample type
From: Kan Liang
Start from Haswell, Linux perf can utilize the existing Last Branch
Record (LBR) facility to record call stack. However, the depth of the
reconstructed LBR call stack limits to the number of LBR registers.
E.g. on skylake, the depth of reconstructed LBR call stack is <= 32
That's
From: Kan Liang
In LBR call stack mode, the depth of reconstructed LBR call stack limits
to the number of LBR registers.
For example, on skylake, the depth of reconstructed LBR call stack is
always <= 32.
# To display the perf.data header info, please use
# --header/--header-only
From: Kan Liang
To stitch LBR call stack, the max LBR information is required. So the
CPU PMU capabilities information has to be stored in perf header.
Add a new feature HEADER_CPU_PMU_CAPS for CPU PMU capabilities.
Retrieve all CPU PMU capabilities, not just max LBR information.
Add variable
On Mon, Oct 07, 2019 at 04:11:53PM +0200, Ondřej Jirman wrote:
> Hi Maxime,
>
> On Fri, Aug 23, 2019 at 12:31:34PM +0200, megous hlavni wrote:
> > From: Ondrej Jirman
> >
> > (Resend to add missing lists, sorry for the noise.)
> >
> > This series implements bluetooth support for Xunlong Orange Pi
Hello,
Aurabindo Jayamohanan wrote:
> {save,restore}_dsp() internally checks if the cpu has dsp support.
> Therefore, explicit check is not required before calling them in
> {save,restore}_processor_state()
Applied to mips-next.
> commit 9662dd752c14
> https://git.kernel.org/mips/c/9662dd752c14
On Mon, Oct 07, 2019 at 10:56:30AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 07, 2019 at 07:55:28PM +0200, Christoph Hellwig wrote:
> > On Mon, Oct 07, 2019 at 01:54:32PM -0400, Arvind Sankar wrote:
> > > It doesn't boot with the patch. Won't it go
> > > dma_get_required_mask
> > > ->
On Mon, Oct 7, 2019 at 12:44 PM John Stultz wrote:
>
> On Tue, Jul 23, 2019 at 9:51 PM Vinod Koul wrote:
> >
> > We get a warning about missing unit name for soc node, so add it.
> >
> > arch/arm64/boot/dts/qcom/sdm845.dtsi:623.11-2814.4: Warning
> > (unit_address_vs_reg): /soc: node has a reg
On 07/10/2019 03:26, Paul E. McKenney wrote:
>
> On Fri, Oct 04, 2019 at 03:24:02PM -0700, Paul E. McKenney wrote:
>> On Fri, Oct 04, 2019 at 07:49:10PM +, Stefan Reiter wrote:
>>> Commit 18cd8c93e69e ("rcu/nocb: Print gp/cb kthread hierarchy if
>>> dump_tree") added print statements to
On Mon, Oct 07, 2019 at 07:55:28PM +0200, Christoph Hellwig wrote:
> On Mon, Oct 07, 2019 at 01:54:32PM -0400, Arvind Sankar wrote:
> > It doesn't boot with the patch. Won't it go
> > dma_get_required_mask
> > -> intel_get_required_mask
> > -> iommu_need_mapping
> > ->
On Sat, Oct 05, 2019 at 06:44:08PM +0200, Borislav Petkov wrote:
> > +static struct sgx_epc_page *sgx_section_get_page(
>
> That fits into 80 cols (oh well, 81) and even if not, a trailing opening
> arg brace is ugly.
But checkpatch.pl will complain about it...
/Jarkko
I've been carrying for awhile some patches that Yu Chen was
previously pushing upstream to enable USB on the HiKey960 board
and I wanted to try to nudge them forward as I'm not sure as to
what his plans are.
This series is just the simpler parts of the patch set that I
wanted to send out to see
From: Yu Chen
It needs more time for the device controller to clear the CmdAct of
DEPCMD on Hisilicon Kirin Soc.
Cc: Greg Kroah-Hartman
Cc: Felipe Balbi
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: Mark Rutland
Cc: Yu Chen
Cc: Matthias Brugger
Cc: Chunfeng Yun
Cc: linux-...@vger.kernel.org
Provide a dt-binding for quirk needed to do a GCTL soft reset on mode
switching
Cc: Greg Kroah-Hartman
Cc: Felipe Balbi
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: Mark Rutland
Cc: Yu Chen
Cc: Matthias Brugger
Cc: Chunfeng Yun
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Add necessary compatible flag for HiSi's DWC3 so
dwc3-of-simple will probe.
Cc: Greg Kroah-Hartman
Cc: Felipe Balbi
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: Mark Rutland
Cc: Yu Chen
Cc: Matthias Brugger
Cc: Chunfeng Yun
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
From: Yu Chen
A GCTL soft reset should be executed when switch mode for dwc3 core
of Hisilicon Kirin Soc.
Cc: Greg Kroah-Hartman
Cc: Felipe Balbi
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: Mark Rutland
Cc: Yu Chen
Cc: Matthias Brugger
Cc: Chunfeng Yun
Cc: linux-...@vger.kernel.org
Cc:
From: Yu Chen
This patch adds support for the poweron and shutdown of dwc3 core
on Hisilicon Soc Platform.
Cc: Greg Kroah-Hartman
Cc: Felipe Balbi
Cc: Andy Shevchenko
Cc: Rob Herring
Cc: Mark Rutland
Cc: Yu Chen
Cc: Matthias Brugger
Cc: Chunfeng Yun
Cc: linux-...@vger.kernel.org
Cc:
On Mon, Oct 07, 2019 at 01:54:32PM -0400, Arvind Sankar wrote:
> It doesn't boot with the patch. Won't it go
> dma_get_required_mask
> -> intel_get_required_mask
> -> iommu_need_mapping
> -> dma_get_required_mask
> ?
>
> Should the call to dma_get_required_mask in
Since we link purgatory.ro with -r aka we enable "incremental linking"
no checks for unresolved symbols is done while linking purgatory.ro.
Changes to the sha256 code has caused the purgatory in 5.4-rc1 to have
a missing symbol on memzero_explicit, yet things still happily build.
This commit
On Mon, Oct 07, 2019 at 09:34:48AM +0200, Christoph Hellwig wrote:
> Hi Arvind,
>
> can you try the patch below?
>
>
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 3f974919d3bd..52b709bf2b55 100644
> --- a/drivers/iommu/intel-iommu.c
> +++
Hello,
Alexandre GRIVEAUX wrote:
> Adding leds and related triggers.
Applied to mips-next.
> commit 24b0cb4f883a
> https://git.kernel.org/mips/c/24b0cb4f883a
>
> Signed-off-by: Alexandre GRIVEAUX
> Signed-off-by: Paul Burton
Thanks,
Paul
[ This message was auto-generated; if you
Hello,
Alexandre GRIVEAUX wrote:
> Add IW8103 Wifi + bluetooth module to device tree and related power domain.
Applied to mips-next.
> commit 948f2708f945
> https://git.kernel.org/mips/c/948f2708f945
>
> Signed-off-by: Alexandre GRIVEAUX
> Signed-off-by: Paul Burton
Thanks,
Paul
[ This
Hello,
Alexandre GRIVEAUX wrote:
> Adding missing I2C nodes and some peripheral:
> - PMU
> - RTC
Applied to mips-next.
> commit 73f2b940474d
> https://git.kernel.org/mips/c/73f2b940474d
>
> Signed-off-by: Alexandre GRIVEAUX
> Signed-off-by: Paul Burton
Thanks,
Paul
[ This message was
Hello,
Thomas Bogendoerfer wrote:
> Most of the SN/SN0 header files are inherited from IRIX header files,
> but not all of that stuff is useful for Linux. Remove not used parts.
Series applied to mips-next.
> MIPS: SGI-IP27: remove not used stuff inherited from IRIX
> commit 46a73e9e6ccc
>
Hello,
Alexandre GRIVEAUX wrote:
> Add the devicetree nodes for the I2C core of the JZ4780 SoC, disabled
> by default.
Applied to mips-next.
> commit f56a040c9faf
> https://git.kernel.org/mips/c/f56a040c9faf
>
> Signed-off-by: Alexandre GRIVEAUX
> Signed-off-by: Paul Burton
Thanks,
Paul
Hello,
Mike Rapoport wrote:
> From: Mike Rapoport
>
> The memory initialization of SGI-IP27 is already half-way to support
> SPARSEMEM. It only had free_bootmem_with_active_regions() left-overs
> interfering with sparse_memory_present_with_active_regions().
>
> Replace these calls with simpler
> PCI memory size 128M 0x20
Correction:
PCI memory size 128G 0x20
Hello,
Paul Burton wrote:
> This series consists of a bunch of cleanups to the way we handle memory
> barriers (though no changes to the sync instructions we use to implement
> them) & atomic memory accesses. One major goal was to ensure the
> Loongson3 LL/SC errata workarounds are applied in a
On Thu, 2019-10-03 at 20:53 -0500, Rob Herring wrote:
> > > > But I think that with this series, given the fact that we now treat the
> > > > lack
> > > > of
> > > > dma-ranges as a 1:1 mapping instead of an error, we could rewrite the
> > > > function
> > > > like this:
> > >
> > > Now, I'm
Hello,
Thomas Bogendoerfer wrote:
> Commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING
> forcibly") allows compiler to uninline functions marked as 'inline'.
> In cace of cmpxchg this would cause to reference function
> __cmpxchg_called_with_bad_pointer, which is a error case
> for
Shutdown the controller when nvme_remove_dead_controller is
reached.
If nvme_remove_dead_controller() is called, the controller won't
be comming back online, so we should shut it down rather than just
disabling.
Remove nvme_kill_queues() as nvme_dev_remove() will take care of
unquiescing queues.
Hi Will,
On 07/10/2019 15:37, Vincenzo Frascino wrote:
> On 07/10/2019 15:15, Will Deacon wrote:
>> On Mon, Oct 07, 2019 at 02:54:29PM +0100, Vincenzo Frascino wrote:
>>> On 07/10/2019 14:31, Will Deacon wrote:
On Thu, Oct 03, 2019 at 06:48:32PM +0100, Vincenzo Frascino wrote:
> This
From: Francois Buergisser
The setting of the motion vectors usage and the setting of motion
vectors address are currently done under different conditions.
When decoding pre-recorded videos, this results of leaving the motion
vectors address unset, resulting in faulty memory accesses. Fix it
by
From: Francois Buergisser
The picture order count table only makes sense for profiles
higher than Baseline. This is confirmed by the H.264 specification
(See 8.2.1 Decoding process for picture order count), which
clarifies how POC are used for features not present in Baseline.
"""
Picture order
From: Jonas Karlman
TRM specify supported image size 48x48 to 4096x2304 at step size 16 pixels,
change frmsize max_width/max_height to match TRM.
Fixes: 760327930e10 ("media: hantro: Enable H264 decoding on rk3288")
Signed-off-by: Jonas Karlman
---
v2:
* No changes.
* Emmanuel Vadot [191007 17:30]:
> On Mon, 7 Oct 2019 09:58:59 -0700
> Tony Lindgren wrote:
> > There should be no need to do that for SoC internal devices, the
> > the default status = "okay" should be just fine. Setting the
> > status = "disabled" for SoC internal devices and then enabling
Commit 953aaa1492c53 ("media: rockchip/vpu: Prepare things to support decoders")
changed the conditions under S_FMT was allowed for OUTPUT
CAPTURE buffers.
However, and according to the mem-to-mem stateless decoder specification,
in order to support dynamic resolution changes, S_FMT should be
Some pending fixes. The first patch is needed to allow
dynamic resolution changes, as per the upcoming stateless
decoder API. This patch was posted before and received
some comments from Philipp Zabel.
The second patch was posted by Jonas Karlman as part
of his series to add support for
On Fri, Oct 4, 2019 at 6:49 PM Alan Mikhak wrote:
>
> From: Alan Mikhak
>
> Modify pci_epc_mem_alloc_addr() to cast the variable 'pageno'
> from type 'int' to 'phys_addr_t' before shifting left. This
> cast is needed to avoid treating bit 31 of 'pageno' as the
> sign bit which would otherwise
On Tue, Jul 23, 2019 at 9:51 PM Vinod Koul wrote:
>
> We get a warning about missing unit name for soc node, so add it.
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi:623.11-2814.4: Warning
> (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit
> name
>
> Signed-off-by: Vinod
From: Andi Kleen
The symbol the feature file checks for is now actually in -lbabeltrace,
not -lbabeltrace-ctf, at least as of libbabeltrace-1.5.6-2.fc30.x86_64
Always add both libraries to fix the feature detection.
Signed-off-by: Andi Kleen
---
tools/perf/Makefile.config | 4 ++--
1 file
> From: linux-hyperv-ow...@vger.kernel.org
> On Behalf Of Andrea Parri
> Sent: Monday, October 7, 2019 9:31 AM
>
> Hi all,
>
> The patchset:
>
> - simplifies/refactors the VMBus negotiation code by introducing
> the table of VMBus protocol versions (patch 1/2),
>
> - enables VMBus protocol
On 2019-10-07 18:56:11 [+0200], Uladzislau Rezki wrote:
> Actually there is a high lock contention on vmap_area_lock, because it
> is still global. You can have a look at last slide:
>
>
On Sun, Oct 06, 2019 at 08:11:42PM -0700, Linus Torvalds wrote:
> > So do we want to bother with separation between raw_copy_to_user() and
> > unsafe_copy_to_user()? After all, __copy_to_user() also has only few
> > callers, most of them in arch/*
>
> No, you're right. Just switch over.
>
> >
On Mon, 7 Oct 2019 at 18:09, Alex Deucher wrote:
>
> On Mon, Oct 7, 2019 at 7:39 AM Jani Nikula
> wrote:
> >
> > On Fri, 04 Oct 2019, Krzysztof Kozlowski wrote:
> > > drivers/gpu/drm/i915/Kconfig | 12 +-
> > > drivers/gpu/drm/i915/Kconfig.debug | 144
Introduce --auto|-a option to base-freq enable feature, so that it
does in one step for users who are OK by setting all cores with higher
base frequency to be set in CLOS 0 and remaining in CLOS 3. This option
also sets corresponding clos.min to CLOS 0 and CLOS3. In this way, users
don't have to
v2
The sequence should be opposite than what was submitted in v1.
First enable core-power than enable turbo-freq and base-freq
for the auto mode. Firmware may give error if the core-power
feature is not enabled first.
Also need to set the core_power property of thread siblings.
Othewise it will
Introduce --auto|-a option to turbo-freq enable feature, so that it
does in one step for users who are OK by setting all passed target cores
as high priority and set in CLOS 0 and remaining in CLOS 3. In this way,
users don't have to take multiple steps to enable turbo-freq feature. For
users who
The turbo-freq feature is dependent on the core-power feature. If the
core-power feature is disabled while the turbo-freq feature is enabled,
this will break the turbo-freq feature. This is a firmware limitation,
where they can't return error under this scenario.
So when trying to disable
On Mon, 7 Oct 2019 09:58:59 -0700
Tony Lindgren wrote:
> * Emmanuel Vadot [191007 16:39]:
> > On Mon, 7 Oct 2019 09:16:34 -0700
> > Tony Lindgren wrote:
> >
> > > Hi,
> > >
> > > * Emmanuel Vadot [191007 08:04]:
> > > > Commit 5b63fb90adb95 ("ARM: dts: Fix incomplete dts data for am3 and
>
From: Alexander Duyck
This patch is meant to address possible race conditions that can exist
between network configuration and power management. A similar issue was
fixed for igb in commit 9474933caf21 ("igb: close/suspend race in
netif_device_detach").
In addition it consolidates the code so
On Mon, Oct 7, 2019 at 10:45 AM H. Nikolaus Schaller wrote:
>
>
> > Am 07.10.2019 um 17:11 schrieb Adam Ford :
> >
> > On Sat, Sep 14, 2019 at 11:12 AM Adam Ford wrote:
> >>
> >> On Sat, Sep 14, 2019 at 9:38 AM H. Nikolaus Schaller
> >> wrote:
> >>>
> >>>
> Am 14.09.2019 um 15:42 schrieb
> From: linux-hyperv-ow...@vger.kernel.org
> On Behalf Of Andrea Parri
> Sent: Monday, October 7, 2019 9:31 AM
>
> +/*
> + * Table of VMBus versions listed from newest to oldest; the table
> + * must terminate with VERSION_INVAL.
> + */
> +__u32 vmbus_versions[] = {
> + VERSION_WIN10_V5,
On Mon, Oct 7, 2019 at 10:12 AM David Z. Dai wrote:
>
> On Mon, 2019-10-07 at 10:02 -0700, Alexander Duyck wrote:
> > On Mon, Oct 7, 2019 at 8:51 AM David Z. Dai wrote:
> > >
> >
> >
> >
> > > We have tested on one of the test box.
> > > With this patch, it doesn't crash kernel anymore, which
On Mon, Oct 07, 2019 at 06:56:11PM +0200, Uladzislau Rezki wrote:
> On Mon, Oct 07, 2019 at 06:34:43PM +0200, Daniel Wagner wrote:
> > I supppose, one thing which would help in this discussion, is what do
> > you gain by using preempt_disable() instead of moving the lock up?
> > Do you have
On Mon, Oct 7, 2019 at 10:07 AM Nitesh Narayan Lal wrote:
>
>
> On 10/7/19 12:27 PM, Alexander Duyck wrote:
> > On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
> >> On 10/7/19 11:33 AM, Alexander Duyck wrote:
> >>> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
>
Andrea Parri writes:
> The technique used to get the next VMBus version seems increasisly
> clumsy as the number of VMBus versions increases. Performance is
> not a concern since this is only done once during system boot; it's
> just that we'll end up with more lines of code than is really
On Mon, 7 Oct 2019 19:04:46 +0200
Sebastian Reichel wrote:
> Hi,
>
> On Mon, Oct 07, 2019 at 06:41:30PM +0200, Andreas Kemnade wrote:
> > When the panels were moved from omap/displays/ to panel/
> > omapdss prefix was stripped, which cause spi modalias
> > to not contain the vendor-prefix
On Mon, Oct 07, 2019 at 07:08:28PM +0200, Paolo Bonzini wrote:
> On 04/10/19 23:56, Sean Christopherson wrote:
> > +#define VMX_FEATURE_RDSEED_EXITING ( 2*32+ 16) /* "" VM-Exit on RDSEED */
> > +#define VMX_FEATURE_PAGE_MOD_LOGGING ( 2*32+ 17) /* "pml" Log dirty
> > pages into buffer */
> >
On Mon, 2019-10-07 at 10:02 -0700, Alexander Duyck wrote:
> On Mon, Oct 7, 2019 at 8:51 AM David Z. Dai wrote:
> >
>
>
>
> > We have tested on one of the test box.
> > With this patch, it doesn't crash kernel anymore, which is good!
> >
> > However we see this warning message from the log file
On 04/10/19 23:56, Sean Christopherson wrote:
> Add support for generating VMX feature names in capflags.c and printing
> the resulting names in /proc/cpuinfo as "vmx flags" when VMX support is
> detected. Do not print VMX flags if no bits are set in word 0, which
> includes Pin controls. INTR
On 04/10/19 23:56, Sean Christopherson wrote:
> + /*
> + * The high bits contain the allowed-1 settings, i.e. features that can
> + * be turned on. The low bits contain the allowed-0 settings, i.e.
> + * features that can be turned off. Ignore the allowed-0 settings,
> +
On 2019-10-07 1:14 a.m., Marc Zyngier wrote:
On Mon, 07 Oct 2019 08:30:50 +0100,
Geert Uytterhoeven wrote:
Hi Chris,
CC MarcZ
On Thu, Oct 3, 2019 at 2:03 AM Chris Packham
wrote:
Use the dev_name(dev) for the irqc->name so that we get unique names
when we have multiple instances of this
On Mon, Oct 07, 2019 at 07:05:32PM +0200, Paolo Bonzini wrote:
> On 04/10/19 23:56, Sean Christopherson wrote:
> > Always lock IA32_FEATURE_CONTROL if it exists, even if the CPU doesn't
> > support VMX, so that other existing and future kernel code that queries
> > IA32_FEATURE_CONTROL can assume
On Mon, 7 Oct 2019 at 02:43, kernelci.org bot wrote:
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation
Remove the unneeded and incorrect read of the TDM_CFG3 register.
The read is done but the value is never used.
Signed-off-by: Dan Murphy
---
v2 - New patch no v1
sound/soc/codecs/tas2770.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/sound/soc/codecs/tas2770.c
Remove unused defines and structure variables that are not
referenced by the code. If these are needed for future
enhancements then they should be added at that time.
Signed-off-by: Dan Murphy
---
v2 - New patch no v1
sound/soc/codecs/tas2770.h | 21 -
1 file changed, 21
According the documentation for snd_soc_update_bits the API
will return a 1 if the update was successful with a value change,
a 0 if the update was successful with no value change or a negative
if the command just failed.
So the value of return in the driver needs to be checked for being less
On 04/10/19 23:56, Sean Christopherson wrote:
> +#define VMX_FEATURE_RDSEED_EXITING ( 2*32+ 16) /* "" VM-Exit on RDSEED */
> +#define VMX_FEATURE_PAGE_MOD_LOGGING ( 2*32+ 17) /* "pml" Log dirty pages
> into buffer */
> +#define VMX_FEATURE_EPT_VIOLATION_VE ( 2*32+ 18) /* "" Conditionally
On Tue, Sep 10, 2019 at 12:59 AM Hsin-Yi Wang wrote:
>
> If devm_iio_channel_get() or devm_thermal_zone_of_sensor_register()
> fail with EPROBE_DEFER, we shouldn't print an error message, as the
> device will be probed again later.
>
> Signed-off-by: Hsin-Yi Wang
> ---
Ping on the thread. Any
On 10/7/19 12:27 PM, Alexander Duyck wrote:
> On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
>> On 10/7/19 11:33 AM, Alexander Duyck wrote:
>>> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
On 10/2/19 10:25 AM, Alexander Duyck wrote:
>> [...]
You
On 10/7/19 9:53 AM, Christoph Hellwig wrote:
On Mon, Oct 07, 2019 at 09:50:31AM -0700, Mark Salyzyn wrote:
On 10/5/19 1:37 AM, Christoph Hellwig wrote:
On Thu, Oct 03, 2019 at 09:55:28AM +0100, Catalin Marinas wrote:
Aren't drivers supposed to use the DMA API for such allocations rather
than
On 10/2/19 9:11 AM, David Laight wrote:
> From: Parth Shah
>> Sent: 30 September 2019 11:44
> ...
>> 5> Separating AVX512 tasks and latency sensitive tasks on separate cores
>> ( -Tim Chen )
>> ===
>> Another usecase we are
On 04/10/19 23:56, Sean Christopherson wrote:
> Always lock IA32_FEATURE_CONTROL if it exists, even if the CPU doesn't
> support VMX, so that other existing and future kernel code that queries
> IA32_FEATURE_CONTROL can assume it's locked.
Possibly stupid question: why bother locking it? It
Jacek
On 10/6/19 2:52 PM, Jacek Anaszewski wrote:
Dan,
On 10/1/19 4:56 PM, Dan Murphy wrote:
Add multicolor framework support for the lp55xx family.
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 1 +
drivers/leds/leds-lp55xx-common.c | 169
On Fri, Sep 27, 2019 at 12:38:49AM +0200, Lukasz Majewski wrote:
> Maybe, it would be sufficient for now to move the spi_slave_abort() in
> spi_release() before we decrease (spidev->users--) the use count?
I think that should be OK, or possibly safer to do it at the start of
the if
transform existing documentation of maxbotix,mb1232 ultrasonic ranger
from text documentation format into yaml.
Changes in v3:
- add a i2c node around device node to set up #address-cells and
#size-cells for omitting error during make dt_binding_check
Changes in v2:
- removed description of
On Mon, Oct 7, 2019 at 8:51 AM David Z. Dai wrote:
>
> We have tested on one of the test box.
> With this patch, it doesn't crash kernel anymore, which is good!
>
> However we see this warning message from the log file for irq number 0:
> [10206.317270] Trying to free already-free IRQ 0
>
>
Hi Rob,
i don't get this error. Is there anything i'm doing wrong here?
ak@arbad:/project/opt-sw/linux-robh$ make O=../build-wega-robh/ dt_binding_check
make[1]: Verzeichnis „/project/opt-sw/build-wega-robh“ wird betreten
SCHEMA Documentation/devicetree/bindings/processed-schema.yaml
301 - 400 of 1218 matches
Mail list logo
