From: Arun Kumar Neelakantam
Extra channel reference put when remote sending OPEN_ACK after timeout
causes use-after-free while handling next remote CLOSE command.
Remove extra reference put in timeout case to avoid use-after-free.
Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink
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 rcu_organize_nocb_kthreads for
> debugging, but incorrectly guarded them, causing the function to always
> spew out its message.
On Fri, Oct 04, 2019 at 11:54:02PM +0200, Jonathan Neuschäfer wrote:
> Without this patch, Sphinx shows "variable arguments" as the description
> of the cond argument, rather than the intended description, and prints
> the following warnings:
>
> ./include/linux/rculist.h:374: warning: Excess
On Thu, Sep 26, 2019 at 10:14 AM Dan Carpenter wrote:
> The pinctrl->functions[] array has pinctrl->num_functions elements and
> the pinctrl->groups[] array is the same way. These are set in
> ns2_pinmux_probe(). So the > comparisons should be >= so that we don't
> read one element beyond the
On Wed, Oct 2, 2019 at 7:02 PM Bartosz Golaszewski wrote:
> This series converts all users of nocache ioremap variants that aren't
> ia64-specific to using devm_platform_ioremap_resource().
Do we have an ia64 gpio driver even?
> Most of these don't call request_mem_region() currently, which
>
This is a RFC patch, which is not intended to be merged as is,
but hopefully will start a discussion which can result in a good
solution for the described problem.
--
We've noticed that the number of dying cgroups on our production hosts
tends to grow with the uptime. This time it's caused by
From: Austin Kim
Date: Fri, 4 Oct 2019 13:52:03 +0900
> 'curr_status' is declared as u32.
> But this variable is not used after below statement.
>curr_status = vptr->mii_status & (~VELOCITY_LINK_FAIL);
>
> This variable could be dropped to mute below warning message:
>
>
On 10/4/19 2:23 PM, Stephen Boyd wrote:
> Git is gaining support to display the closest node to the diff in the
> hunk header via the 'dts' diff driver. Use that driver for all dts and
> dtsi files so we can gain some more context on where the diff is. Taking
> a recent commit in the kernel dts
From: Vitaly Kuznetsov Sent: Friday, October 4, 2019 9:57
AM
>
> Andrea Parri writes:
>
> > If the hardware supports TSC scaling, Hyper-V will set bit 15 of the
> > HV_PARTITION_PRIVILEGE_MASK in guest VMs with a compatible Hyper-V
> > configuration version. Bit 15 corresponds to the
> >
On Fri, Oct 4, 2019 at 6:59 PM Andrey Smirnov wrote:
>
> Fix incorrect read-modify-write sequence in lpuart_flush_buffer() that
> was reading from UARTPFIFO and writing to UARTCFIFO instead of
> operating solely on the latter.
>
> Fixes: 9bc19af9dacb ("tty: serial: fsl_lpuart: Flush HW FIFOs in
On Wed, Oct 2, 2019 at 2:28 PM Thierry Reding wrote:
> From: Timo Alho
>
> The interrupt-related register fields on the MAX77620 GPIO controller
> share registers with GPIO related fields. If the IRQ chip is implemented
> with regmap-irq, this causes the IRQ controller code to overwrite fields
Hi "Joel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on rcu/dev]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to sp
On Wed, Oct 2, 2019 at 2:28 PM Thierry Reding wrote:
> From: Thierry Reding
>
> regmap_add_irq_chip() will try to allocate all of the IRQ descriptors
> upfront if passed a non-zero irq_base parameter. However, the intention
> is to allocate IRQ descriptors on an as-needed basis if possible.
On Wed, Oct 2, 2019 at 2:28 PM Thierry Reding wrote:
> From: Thierry Reding
>
> The gpiod_set_debounce() function takes the debounce time in
> microseconds. Adjust the switch/case values in the MAX77620 GPIO to use
> the correct unit.
>
> Signed-off-by: Thierry Reding
Patch applied for fixes.
WARN if the IA32_FEATURE_CONTROL MSR is somehow left unlocked now that
CPU initialization unconditionally locks the MSR.
Signed-off-by: Sean Christopherson
---
arch/x86/kernel/cpu/mce/intel.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
Opportunistically initialize IA32_FEATURE_CONTROL MSR to enable VMX when
the MSR is left unlocked by BIOS. Configuring IA32_FEATURE_CONTROL at
boot time paves the way for similar enabling of other features, e.g.
Software Guard Extensions (SGX).
Temporarily leave equivalent KVM code in place in
Replace KVM's manual checks on IA32_FEATURE_CONTROL with a query on the
boot CPU's VMX feature flag. The VMX flag is now cleared during boot if
VMX isn't fully enabled via IA32_FEATURE_CONTROL, including the case
where IA32_FEATURE_CONTROL isn't supported.
Signed-off-by: Sean Christopherson
---
Explicitly check the current CPU's VMX feature flag when verifying
compatibility across physical CPUs. This effectively adds a check on
IA32_FEATURE_CONTROL to ensure that VMX is fully enabled on all CPUs.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/vmx.c | 5 +
1 file changed,
Use the recently added IA32_FEATURE_CONTROL MSR initialization sequence
to opportunstically enable VMX support when running on a Zhaoxin CPU.
Signed-off-by: Sean Christopherson
---
arch/x86/Kconfig.cpu | 2 +-
arch/x86/kernel/cpu/zhaoxin.c | 2 ++
2 files changed, 3 insertions(+), 1
Shift the remaining synthetic virtualization flags so that the flags
are contiguous starting from bit 0.
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/cpufeatures.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Provide stubs for perf_guest_get_msrs() and intel_pt_handle_vmx() when
building without support for Intel CPUs, i.e. CPU_SUP_INTEL=n. Lack of
stubs is not currently a problem as the only user, KVM_INTEL, takes a
dependency on CPU_SUP_INTEL=y. Provide the stubs for all CPUs so that
KVM_INTEL can
Remove the synthetic VMX feature flags from word 8 as they have been
superseded by VMX_FEATURE_*.
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/cpufeatures.h | 7 ---
1 file changed, 7 deletions(-)
diff --git
Define the VMCS execution control flags (consumed by KVM) using their
associated VMX_FEATURE_* to provide a strong hint that new VMX features
are expected to be added to VMX_FEATURE and considered for reporting via
/proc/cpuinfo.
No functional change intended.
Signed-off-by: Sean Christopherson
Add a VMX specific variant of X86_FEATURE_* flags, which will eventually
supplant the synthetic VMX flags defined in cpufeatures word 8. Use the
Intel-defined layouts for the major VMX execution controls so that their
word entries can be directly populated from their respective MSRs, and
so that
Now that the IA32_FEATURE_CONTROL MSR is guaranteed to be configured and
locked, clear the VMX capability flag if the IA32_FEATURE_CONTROL MSR is
not supported or if BIOS disabled VMX, i.e. locked IA32_FEATURE_CONTROL
and did not set the appropriate VMX enable bit.
Signed-off-by: Sean
Fix incorrect read-modify-write sequence in lpuart_flush_buffer() that
was reading from UARTPFIFO and writing to UARTCFIFO instead of
operating solely on the latter.
Fixes: 9bc19af9dacb ("tty: serial: fsl_lpuart: Flush HW FIFOs in .flush_buffer")
Signed-off-by: Andrey Smirnov
Cc: Stefan Agner
Clean up a handful of interrelated warts in the kernel's handling of VMX:
- Enable VMX in IA32_FEATURE_CONTROL during boot instead of on-demand
during KVM load to avoid future contention over writing the MSR.
- Rework VMX feature reporting so that it is accurate and up-to-date,
now
Add an entry in struct cpuinfo_x86 to track VMX capabilities and fill
the capabilities during IA32_FEATURE_CONTROL MSR initialization.
Make the VMX capabilities dependent on X86_INTEL_FEATURE_CONTROL and
X86_FEATURE_NAMES so as to avoid unnecessary overhead on CPUs that can't
possibly support
Remove the code to initialize IA32_FEATURE_CONTROL MSR when KVM is
loaded now that the MSR is initialized during boot on all CPUs that
support VMX, i.e. can possibly load kvm_intel.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/vmx.c | 48 +-
1
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 and NMI exiting are fundamental pillars of
Change the dependency for KVM_INTEL, i.e. KVM w/ VMX, from Intel CPUs to
any CPU that has IA32_FEATURE_CONTROL MSR and thus VMX functionality.
This effectively allows building KVM_INTEL for Centaur and Zhaoxin CPUs.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/Kconfig | 9 -
1
Use the recently added IA32_FEATURE_CONTROL MSR initialization sequence
to opportunstically enable VMX support when running on a Centaur CPU.
Signed-off-by: Sean Christopherson
---
arch/x86/Kconfig.cpu | 2 +-
arch/x86/kernel/cpu/centaur.c | 2 ++
2 files changed, 3 insertions(+), 1
Without this patch, Sphinx shows "variable arguments" as the description
of the cond argument, rather than the intended description, and prints
the following warnings:
./include/linux/rculist.h:374: warning: Excess function parameter 'cond'
description in 'list_for_each_entry_rcu'
On Tue, Oct 1, 2019 at 5:49 PM Patrick Williams wrote:
> The 37xx configuration registers are only 32 bits long, so
> pins 32-35 spill over into the next register. The calculation
> for the register address was done, but the bitmask was not, so
> any configuration to pin 32 or above resulted in
On Thu, Oct 3, 2019 at 10:41 PM Andrey Smirnov wrote:
>
> Specify 'i2c-mux-idle-disconnect' for both I2C switches present on the
> board, since both are connected to the same parent bus and all of
> their children have the same I2C address.
>
> Fixes: ca4b4d373fcc ("ARM: dts: vf610: Add ZII SCU4
Am Mittwoch, 4. September 2019, 14:29:33 CEST schrieb YueHaibing:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Reviewed-by: Heiko Stuebner
> ---
>
On Tue, Oct 1, 2019 at 4:56 PM Dan Murphy wrote:
> Add the reg property to each channel node. This update is
> to accomodate the multicolor framework. In addition to the
> accomodation this allows the LEDs to be placed on any channel
> and allow designs to skip channels as opposed to requiring
On Mon, 2019-09-16 at 14:38 -0700, Palmer Dabbelt wrote:
> On Mon, 16 Sep 2019 12:40:10 PDT (-0700), sch...@suse.de wrote:
> > On Sep 16 2019, Palmer Dabbelt wrote:
> >
> > > On Sun, 15 Sep 2019 23:42:53 PDT (-0700), Christoph Hellwig
> > > wrote:
> > > > On Fri, Sep 13, 2019 at 01:40:27PM
Hi Vivek,
Am Montag, 30. September 2019, 01:46:15 CEST schrieb Vivek Unune:
> On Sun, Sep 29, 2019 at 01:22:17PM +0200, Vicente Bergas wrote:
> > On Sunday, September 29, 2019 5:22:30 AM CEST, Vivek Unune wrote:
> > > Fix usb-c on X99 TV Box. Tested with armbian w/ kernel 5.3
> > >
> > >
Use the more modern API to get the match data out of the of match table.
This saves some code, lines, and nicely avoids referencing the match
table when it is undefined with configurations where CONFIG_OF=n.
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory
Use the more modern API here instead of using of_match_device() and
avoid casting away const from the returned pointer by pushing the const
type through to the users. This nicely avoids referencing the match
table when it is undefined with configurations where CONFIG_OF=n and
avoids const issues.
This probe function is only called if the device is backed by a DT node,
so switch this call to of_device_get_match_data() to reduce code size
and simplify a bit. This also avoids needing to reference a potentially
undefined variable because of_device_get_match_data() doesn't need to
know anything
This effectively reverts 1db73ae39a97 ("of/device: Nullify match table
in of_match_device() for CONFIG_OF=n") because that commit makes it more
surprising to users of this API that the arguments may never be
referenced by any code. This is because the pre-processor will replace
the argument with
This driver casts away the constness of struct stm32_usart_info that is
pointed to by the of match table. Use of_device_get_match_data() instead
of of_match_device() here and push the const throughout the code so that
we don't cast away const. This nicely avoids referencing the match table
when it
of_match_device() uses of_match_ptr() to make the match table argument
NULL via the pre-processor when CONFIG_OF=n. This makes life harder for
compilers who think that match tables are never used and warn about
unused variables when CONFIG_OF=n. This series changes various callers
to use
This driver doesn't do anything with the match for the device node. The
logic is the same as looking to see if a device node exists or not
because this driver wouldn't probe unless there is a device node match
when the device is created from DT. Just test for the presence of the
device node to
We're going to remove of_match_ptr() from the definition of
of_match_device() when CONFIG_OF=n. This way we can always be certain
that of_match_device() acts the same when CONFIG_OF is set and when it
isn't. Add of_match_ptr() here so that this doesn't break when that
change is made to the
This driver can use the of_device_get_match_data() API to simplify the
code. Replace calls to of_match_device() with this newer API under the
assumption that where it is called will be when we know the device is
backed by a DT node. This nicely avoids referencing the match table when
it is
Use the more modern API to get the match data out of the of match table.
This saves some code, lines, and nicely avoids referencing the match
table when it is undefined with configurations where CONFIG_OF=n.
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Grygorii Strashko
Cc: "David S. Miller"
This driver can use the replacement API instead of calling
of_match_device() and then dereferencing the pointer that is returned.
This nicely avoids referencing the match table when it is undefined with
configurations where CONFIG_OF=n.
Cc: Arnd Bergmann
Cc: Geert Uytterhoeven
Cc: Jacopo Mondi
On Fri, Sep 27, 2019 at 10:28 AM Baolin Wang wrote:
> Use devm_hwspin_lock_register() to register the hwlock controller instead of
> unregistering the hwlock controller explicitly when removing the device.
>
> Signed-off-by: Baolin Wang
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, Sep 27, 2019 at 10:28 AM Baolin Wang wrote:
> Use devm_kzalloc() to allocate memory.
>
> Signed-off-by: Baolin Wang
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, Sep 27, 2019 at 10:28 AM Baolin Wang wrote:
> Use the new helper that wraps the calls to platform_get_resource()
> and devm_ioremap_resource() together, which can simpify the code.
>
> Signed-off-by: Baolin Wang
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Wed, Sep 25, 2019 at 7:41 PM Dan Murphy wrote:
> Add the reg property to each channel node. This update is
> to accomodate the multicolor framework. In addition to the
> accomodation this allows the LEDs to be placed on any channel
> and allow designs to skip channels as opposed to
On Mon, Sep 23, 2019 at 4:20 PM Rasmus Villemoes
wrote:
> The helper pinctrl_dt_has_hogs() was introduced in
> 99e4f67508e1 (pinctrl: core: Use delayed work for hogs), but the sole
> use then got removed shortly after in 950b0d91dc10 (pinctrl: core: Fix
> regression caused by delayed work for
On Mon, Sep 23, 2019 at 3:33 PM Paul Kocialkowski
wrote:
> Maybe a first step would be to introduce Kconfig options for each device and
> ifdef around in the code, as to solve the "built unconditionally" aspect?
ifdefs is something we try to avoid using too much, better for things
to have their
Git is gaining support to display the closest node to the diff in the
hunk header via the 'dts' diff driver. Use that driver for all dts and
dtsi files so we can gain some more context on where the diff is. Taking
a recent commit in the kernel dts files you can see the difference.
With this patch
On 10/4/19 2:13 PM, David Miller wrote:
> From: Florian Fainelli
> Date: Thu, 3 Oct 2019 11:43:50 -0700
>
>> This patch series fixes the BCM54210E RGMII delay configuration which
>> could only have worked in a PHY_INTERFACE_MODE_RGMII configuration.
>> There is a forward declaration added such
On 9/25/19 10:58 AM, Jeroen Hofstee wrote:
> While the state changes are reported when the error counters increase
> and decrease, there is no event when the bus recovers and the error
> counters decrease again. So add those as well.
>
> Change the state going downward to be ERROR_PASSIVE ->
From: Florian Fainelli
Date: Thu, 3 Oct 2019 11:43:50 -0700
> This patch series fixes the BCM54210E RGMII delay configuration which
> could only have worked in a PHY_INTERFACE_MODE_RGMII configuration.
> There is a forward declaration added such that the first patch can be
> picked up for
On 9/28/19 4:29 PM, Wen Yang wrote:
> of_node_put needs to be called when the device node which is got
> from of_get_child_by_name finished using.
>
> fixes: 2290aefa2e90 ("can: dev: Add support for limiting configured bitrate")
> Signed-off-by: Wen Yang
> Cc: Wolfgang Grandegger
> Cc: Marc
On 9/30/19 11:49 AM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Applied to linux-can-next.
tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde
On Fri, Sep 20, 2019 at 2:20 PM Colin King wrote:
> From: Colin Ian King
>
> The call to pinctrl_count_index_with_args checks for a -EINVAL return
> however this function calls pinctrl_get_list_and_count and this can
> return -ENOENT. Rather than check for a specific error, fix this by
>
On Fri, Sep 20, 2019 at 11:23 AM Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 20 Sep 2019 10:52:56 +0200
>
> Simplify this function implementation by using the wrapper function
> “devm_platform_ioremap_resource” instead of calling the functions
> “platform_get_resource” and
On Fri, Oct 04, 2019 at 01:48:34PM -0700, Jim Mattson wrote:
> On Tue, Sep 17, 2019 at 1:52 AM Yang Weijiang wrote:
> > @@ -7521,6 +7527,10 @@ static __init int hardware_setup(void)
> > if (!cpu_has_vmx_flexpriority())
> > flexpriority_enabled = 0;
> >
> > + if
Hello,
Let us repair your phone or gadget right on the spot
visit us today
https://www.justrepair.net
or come into our location
https://goo.gl/maps/k5iRbeJyggiXnZSG6
Give us a nice review and we`ll make you a big discount
Thank you,
Ameer
From: David Howells
Date: Thu, 03 Oct 2019 17:45:57 +0100
> There was supposed to be a trace indicating that a new peer had been
> created. Add it.
>
> Signed-off-by: David Howells
Applied.
From: David Howells
Date: Thu, 03 Oct 2019 17:44:44 +0100
> Fix the rxrpc_recvmsg tracepoint to handle being called with a NULL call
> parameter.
>
> Fixes: a25e21f0bcd2 ("rxrpc, afs: Use debug_ids rather than pointers in
> traces")
> Signed-off-by: David Howells
Applied and queued up for
On Fri, Oct 4, 2019 at 11:09 AM Harshad Shirwadkar
wrote:
>
> scale_up wakes up waiters after scaling up. But after scaling max, it
> should not wake up more waiters as waiters will not have anything to
> do. This patch fixes this by making scale_up (and also scale_down)
> return when threshold
On Tue, Sep 17, 2019 at 1:52 AM Yang Weijiang wrote:
>
> Check SPP capability in MSR_IA32_VMX_PROCBASED_CTLS2, its 23-bit
> indicates SPP capability. Enable SPP feature bit in CPU capabilities
> bitmap if it's supported.
>
> Co-developed-by: He Chen
> Signed-off-by: He Chen
> Co-developed-by:
On 10/1/19 12:29 PM, Johan Hovold wrote:
> Syzbot reported a use-after-free on disconnect in mcba_usb and a quick
> grep revealed a similar issue in usb_8dev.
>
> Compile-tested only.
Applied to can.
tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on efi/next]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base
On 9/25/19 1:45 PM, Pankaj Sharma wrote:
> According to the CAN Specification (see ISO 11898-1:2015, 8.3.4
> Recovery Management), the M_CAN provides means for automatic
> retransmission of frames that have lost arbitration or that
> have been disturbed by errors during transmission. By default
>
On Fri, Aug 09, 2019 at 12:28:43PM +0200, Lukas Wunner wrote:
> A sysfs request to enable or disable a PCIe hotplug slot should not
> return before it has been carried out. That is sought to be achieved
> by waiting until the controller's "pending_events" have been cleared.
>
> However the IRQ
The pull request you sent on Fri, 4 Oct 2019 08:22:03 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
> tags/devicetree-fixes-for-5.4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a4ad51e9528e614a60c8828901ee9d7b9f4538d5
Thank you!
--
The pull request you sent on Fri, 4 Oct 2019 20:05:28 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git
> tags/mips_fixes_5.4_1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4ea655343ce4180fe9b2c7ec8cb8ef9884a47901
Thank you!
--
Deet-doot-dot,
The pull request you sent on Fri, 4 Oct 2019 10:36:54 -0700 (PDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
> tags/riscv/for-v5.4-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/812ad49d88b51fab551acb3c2d9c7d054bc69423
Thank you!
--
On Fri, Oct 04, 2019 at 09:35:23AM +, claudiu.bez...@microchip.com wrote:
> Hi Kamel,
>
> On 02.10.2019 17:46, Kamel Bouhara wrote:
> > +static int at91_init_twi_recovery_info(struct platform_device *pdev,
> > + struct at91_twi_dev *dev)
> > +{
> > + struct
On 04.10.19 22:18, Heiko Stuebner wrote:
> Hi Sören,
>
> Am Freitag, 4. Oktober 2019, 22:15:45 CEST schrieb Soeren Moch:
>> Heiko,
>>
>> since you started to apply the first 2 Patches of this series (thanks
>> for that!), now after all the discussions here (and the heads-up for the
>>
According to the RockPro64 schematic [1] the rk3399 sdmmc controller is
connected to a microSD (TF card) slot. Remove the cap-mmc-highspeed
property of the sdmmc controller, since no mmc card can be connected here.
[1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
Fixes:
Mark
On 10/4/19 3:26 PM, Mark Brown wrote:
On Fri, Oct 04, 2019 at 03:22:45PM -0500, Dan Murphy wrote:
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -395,6 +395,7 @@ CONFIG_SND_SOC_OMAP_ABE_TWL6040=m
CONFIG_SND_SOC_OMAP_HDMI=m
Hi Rahul,
this is an interesting patch!
Let's dive in and fix the things not already pointed out in review.
It will need some work but I am sure you can get there.
On Thu, Sep 12, 2019 at 9:59 AM Rahul Tanwar
wrote:
> Intel Lightning Mountain SoC has a pinmux controller & GPIO controller IP
On Fri, Oct 04, 2019 at 03:22:45PM -0500, Dan Murphy wrote:
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -395,6 +395,7 @@ CONFIG_SND_SOC_OMAP_ABE_TWL6040=m
> CONFIG_SND_SOC_OMAP_HDMI=m
> CONFIG_SND_SOC_CPCAP=m
> CONFIG_SND_SOC_TLV320AIC23_I2C=m
On Fri, Oct 04, 2019 at 10:08:04PM +0200, Uwe Kleine-König wrote:
> On Fri, Oct 04, 2019 at 09:09:51AM +, Benjamin GAIGNARD wrote:
> > like for the your patch in IIO trigger regmap_read could only failed
> > if the hardware block is no more clocked and in this case we won't
> > return of
On Fri, Oct 4, 2019 at 10:36 AM Paul Walmsley wrote:
>
> - Ensure that exclusive-load reservations are terminated after system
> call or exception handling. This primarily affects QEMU, which does
> not expire load reservations.
Grr. Can somebody talk sense to the RISC-V architects?
In ql_alloc_large_buffers, a new skb is allocated via netdev_alloc_skb.
This skb should be released if pci_dma_mapping_error fails.
Fixes: 0f8ab89e825f ("qla3xxx: Check return code from pci_map_single() in
ql_release_to_lrg_buf_free_list(), ql_populate_free_queue(),
ql_alloc_large_buffers(),
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
Hi Sören,
Am Freitag, 4. Oktober 2019, 22:15:45 CEST schrieb Soeren Moch:
> Heiko,
>
> since you started to apply the first 2 Patches of this series (thanks
> for that!), now after all the discussions here (and the heads-up for the
> implemented mode detection) I think we should leave the
In mwifiex_pcie_init_evt_ring, a new skb is allocated which should be
released if mwifiex_map_pci_memory() fails. The release for skb and
card->evtbd_ring_vbase is added.
Fixes: 0732484b47b5 ("mwifiex: separate ring initialization and ring creation
routines")
Signed-off-by: Navid Emamdoost
---
Heiko,
since you started to apply the first 2 Patches of this series (thanks
for that!), now after all the discussions here (and the heads-up for the
implemented mode detection) I think we should leave the vcc_sdio
regulator settings unmodified.
It still could make sense to remove the
On Thu, 2019-10-03 at 08:11 -0400, Prarit Bhargava wrote:
> Add functionality for perf-profile info on CascadeLake-N.
Also the display is not correct. It will show redundant info for both
packages.
#intel-speed-select perf-profile info
Intel(R) Speed Select Technology
Executing on CPU
On Fri Oct 04 19, Jerry Snitselaar wrote:
On Fri Oct 04 19, James Bottomley wrote:
On Fri, 2019-10-04 at 11:33 -0700, Jerry Snitselaar wrote:
On Fri Oct 04 19, James Bottomley wrote:
On Fri, 2019-10-04 at 21:22 +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 03, 2019 at 04:59:37PM -0700, James
On Fri, Oct 4, 2019 at 5:40 AM wrote:
>
> From: Patrice Chotard
>
> SPI_STM32_QSPI must be set in buildin as rootfs can be
> located on QSPI memory device.
>
> Signed-off-by: Patrice Chotard
> ---
> arch/arm/configs/multi_v7_defconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Fri, 2019-10-04 at 07:56 -0700, Andy Lutomirski wrote:
> On Thu, Oct 3, 2019 at 2:38 PM Rick Edgecombe
> wrote:
> >
> > This patchset enables the ability for KVM guests to create execute-only (XO)
> > memory by utilizing EPT based XO permissions. XO memory is currently
> > supported
> > on
On Mon, Sep 30, 2019 at 07:27:43PM +0200, Greg KH wrote:
> On Mon, Sep 30, 2019 at 07:22:39PM +0200, Pavel Machek wrote:
> > On Mon 2019-09-30 15:39:02, Greg KH wrote:
> > > On Sat, Aug 10, 2019 at 09:13:22AM +0200, Pavel Machek wrote:
> > > > On Fri 2019-08-09 17:52:46, Guru Das Srinagesh wrote:
In mwifiex_pcie_alloc_cmdrsp_buf, a new skb is allocated which should be
released if mwifiex_map_pci_memory() fails. The release is added.
Fixes: fc3314609047 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe")
Signed-off-by: Navid Emamdoost
---
drivers/net/wireless/marvell/mwifiex/pcie.c
Hello,
Cc += Mark Brown who maintains regmap
On Fri, Oct 04, 2019 at 09:09:51AM +, Benjamin GAIGNARD wrote:
>
> On 10/4/19 8:23 AM, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Thu, Oct 03, 2019 at 09:46:49PM -0700, Yizhuo wrote:
> >> Inside function stm32_pwm_config(), variable "psc" and
Hi Linus,
Here is a selection of fixes for arch/mips, mostly handling regressions
introduced during the v5.4 merge window; please pull.
Thanks,
Paul
The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c:
Linux 5.4-rc1 (2019-09-30 10:35:40 -0700)
are available in
Am Donnerstag, 3. Oktober 2019, 23:50:35 CEST schrieb Soeren Moch:
> The RockPro64 schematics [1], [2] show that the rk3399 EMMC_STRB pin is
> connected to the RESET pin instead of the DATA_STROBE pin of the eMMC module.
> So the data strobe cannot be used for its intended purpose on this board,
>
Am Donnerstag, 3. Oktober 2019, 23:50:34 CEST schrieb Soeren Moch:
> The RockPro64 schematic [1] page 18 states a min voltage of 0.8V and a
> max voltage of 1.4V for the VDD_LOG pwm regulator. However, there is an
> additional note that the pwm parameter needs to be modified.
> From the schematics
101 - 200 of 846 matches
Mail list logo
