Julia Lawall wrote:
> Replace commas with semicolons. What is done is essentially described by
> the following Coccinelle semantic patch (http://coccinelle.lip6.fr/):
>
> //
> @@ expression e1,e2; @@
> e1
> -,
> +;
> e2
> ... when any
> //
>
> Signed-off-by: Julia Lawall
Patch applied to
On Thu, Sep 24, 2020 at 11:21:10AM +0800, Jason Wang wrote:
> This patches introduces the multiple address spaces support for vDPA
> device. This idea is to identify a specific address space via an
> dedicated identifier - ASID.
>
> During vDPA device allocation, vDPA device driver needs to
On Thu, Oct 01, 2020 at 04:20:12PM +0300, Vladimir Oltean wrote:
> Add the description of the embedded L2 switch inside the SoC dtsi file
> for NXP T1040.
>
> Signed-off-by: Vladimir Oltean
> Reviewed-by: Maxim Kochetkov
Reviewed-by: Andrew Lunn
Andrew
On Thu, Oct 01, 2020 at 04:20:13PM +0300, Vladimir Oltean wrote:
> Define the network interface names for the switch ports and hook them up
> to the 2 QSGMII PHYs that are onboard.
>
> A conscious decision was taken to go along with the numbers that are
> written on the front panel of the board
On Thu, Sep 24, 2020 at 11:21:10AM +0800, Jason Wang wrote:
> This patches introduces the multiple address spaces support for vDPA
> device. This idea is to identify a specific address space via an
> dedicated identifier - ASID.
>
> During vDPA device allocation, vDPA device driver needs to
On 10/1/20 3:28 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This is considered bad for the following reasons:
> (1) We only support the block protection with BPn bits for write
> protection. Not all Atmel parts
On 10/1/20 11:13 AM, Thomas Gleixner wrote:
On Wed, Sep 30 2020 at 11:12, Alexei Starovoitov wrote:
For the last couple years we've been using mb2q tool to normalize patches
and it worked wonderfully.
Fun. I thought I'm the only user of it :)
We're using it pretty much daily since you've
Define the network interface names for the switch ports and hook them up
to the 2 QSGMII PHYs that are onboard.
A conscious decision was taken to go along with the numbers that are
written on the front panel of the board and not with the hardware
numbers of the switch chip ports. The 2 numbering
Seville is a DSA switch that is embedded inside the T1040 SoC, and
supported by the mscc_seville DSA driver inside drivers/net/dsa/ocelot.
This series adds this switch to the SoC's dtsi files and to the T1040RDB
board file.
Vladimir Oltean (2):
powerpc: dts: t1040: add bindings for Seville
Add the description of the embedded L2 switch inside the SoC dtsi file
for NXP T1040.
Signed-off-by: Vladimir Oltean
Reviewed-by: Maxim Kochetkov
---
Changes in v3:
Added definition for frame extraction interrupt, even if the driver
doesn't use it at the moment.
Changes in v2:
Make switch node
Hi Sami,
On Tue, 29 Sep 2020, Sami Tolvanen wrote:
> From: Peter Zijlstra
>
> Add the --mcount option for generating __mcount_loc sections
> needed for dynamic ftrace. Using this pass requires the kernel to
> be compiled with -mfentry and CC_USING_NOP_MCOUNT to be defined
> in Makefile.
>
>
On Thu, 2020-10-01 at 16:03 +0530, Dwaipayan Ray wrote:
> Checkpatch.pl doesn't have a check for excluding while (...) {...}
> blocks from MULTISTATEMENT_MACRO_USE_DO_WHILE error.
>
> For example, running checkpatch.pl on the file mm/access.c in the
> kernel generates the following error:
>
>
On Thu, Oct 01, 2020 at 08:50:55AM -0400, Qian Cai wrote:
> Calling pipe2() with O_NOTIFICATION_PIPE could results in memory leaks
> in an error path or CONFIG_WATCH_QUEUE=n. Plug them.
[snip the copy of bug report]
No objections on the patch itself, but commit message is just about
unreadable.
On 01.10.20 14:59, Krzysztof Kozlowski wrote:
On Thu, Oct 01, 2020 at 02:06:59PM +0200, Schrempf Frieder wrote:
From: Frieder Schrempf
Add entries for the SoMs and boards based on i.MX8MM from Kontron
Electronics GmbH.
Signed-off-by: Frieder Schrempf
Reviewed-by: Rob Herring
---
Changes
On 01.10.20 14:34, Schrempf Frieder wrote:
From: Frieder Schrempf
In order to use ultra high speed modes (UHS) on the SD card slot, we
add matching pinctrls and fix the voltage switching for LDO5 of the
PMIC, by providing the SD_VSEL pin as GPIO to the PMIC driver.
Signed-off-by: Frieder
Wei Liu writes:
> On Thu, Oct 01, 2020 at 11:40:04AM +0200, Vitaly Kuznetsov wrote:
>> Sasha Levin writes:
>>
>> > cpumask can change underneath us, which is generally safe except when we
>> > call into hv_cpu_number_to_vp_number(): if cpumask ends up empty we pass
>> > num_cpu_possible() into
On Thu, Oct 1, 2020 at 3:05 PM Dmitry Vyukov wrote:
>
> On Wed, Sep 30, 2020 at 8:06 PM David Sterba wrote:
> >
> > On Wed, Sep 30, 2020 at 06:57:56PM +0200, David Sterba wrote:
> > > On Sun, Sep 20, 2020 at 07:12:14AM -0700, syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot found the
As vcpu->arch.cpuid_entries is now allocated dynamically, the only
remaining use for KVM_MAX_CPUID_ENTRIES is to check KVM_SET_CPUID/
KVM_SET_CPUID2 input for sanity. Since it was reported that the
current limit (80) is insufficient for some CPUs, bump
KVM_MAX_CPUID_ENTRIES and use an arbitrary
The current limit for guest CPUID leaves (KVM_MAX_CPUID_ENTRIES, 80)
is reported to be insufficient but before we bump it let's switch to
allocating vcpu->arch.cpuid_entries[] array dynamically. Currently,
'struct kvm_cpuid_entry2' is 40 bytes so vcpu->arch.cpuid_entries is
3200 bytes which
As a preparatory step to allocating vcpu->arch.cpuid_entries dynamically
make kvm_check_cpuid() check work with an arbitrary 'struct kvm_cpuid_entry2'
array.
Currently, when kvm_check_cpuid() fails we reset vcpu->arch.cpuid_nent to
0 and this is kind of weird, i.e. one would expect CPUIDs to
On Wed, Sep 30, 2020 at 8:06 PM David Sterba wrote:
>
> On Wed, Sep 30, 2020 at 06:57:56PM +0200, David Sterba wrote:
> > On Sun, Sep 20, 2020 at 07:12:14AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:eb5f95f1 Merge tag
Changes since RFC:
- "KVM: x86: disconnect kvm_check_cpuid() from vcpu->arch.cpuid_entries"
added to allow running kvm_check_cpuid() before vcpu->arch.cpuid_entries/
vcpu->arch.cpuid_nent are changed [Sean Christopherson]
- Shorten local variable names in kvm_vcpu_ioctl_set_cpuid[,2]
[Sean
On Thu, Oct 01, 2020 at 11:53:59AM +, Wei Liu wrote:
On Thu, Oct 01, 2020 at 11:40:04AM +0200, Vitaly Kuznetsov wrote:
Sasha Levin writes:
> cpumask can change underneath us, which is generally safe except when we
> call into hv_cpu_number_to_vp_number(): if cpumask ends up empty we pass
On Thu, Oct 01, 2020 at 02:06:58PM +0200, Schrempf Frieder wrote:
> From: Frieder Schrempf
>
> Kontron Electronics GmbH offers small and powerful SoMs based on the
> i.MX8M Mini SoC including PMIC, LPDDR4-RAM, eMMC and SPI NOR.
>
> The matching baseboards have the same form factor and similar
On 01.10.20 14:53, Mark Brown wrote:
On Thu, Oct 01, 2020 at 02:34:31PM +0200, Schrempf Frieder wrote:
+ pca9450->sd_vsel_gpio = gpiod_get_optional(pca9450->dev, "sd-vsel",
GPIOD_OUT_HIGH);
We need a patch adding this to the binding document too.
Right, totally forgot about that.
On Thu, Sep 24, 2020 at 05:50:37PM +0700, Suravee Suthikulpanit wrote:
>
>
> On 9/24/20 5:34 PM, Joerg Roedel wrote:
> > Hi Suravee,
> >
> > On Wed, Sep 23, 2020 at 10:14:29AM +, Suravee Suthikulpanit wrote:
> > > The framework allows callable implementation of IO page table.
> > > This
On Thu, Oct 01, 2020 at 02:06:59PM +0200, Schrempf Frieder wrote:
> From: Frieder Schrempf
>
> Add entries for the SoMs and boards based on i.MX8MM from Kontron
> Electronics GmbH.
>
> Signed-off-by: Frieder Schrempf
> Reviewed-by: Rob Herring
> ---
> Changes for v3:
> * None
>
> Changes for
On Thu, Oct 01, 2020 at 02:06:58PM +0200, Schrempf Frieder wrote:
> From: Frieder Schrempf
>
> Kontron Electronics GmbH offers small and powerful SoMs based on the
> i.MX8M Mini SoC including PMIC, LPDDR4-RAM, eMMC and SPI NOR.
>
> The matching baseboards have the same form factor and similar
On 01/10/2020 12:25, Daniel Vetter wrote:
On Thu, Oct 1, 2020 at 12:58 PM Steven Price wrote:
On 21/09/2020 14:10, Qinglang Miao wrote:
Simplify the return expression.
Signed-off-by: Qinglang Miao
Reviewed-by: Steven Price
As committer/maintainer for this please indicate whether
On Wed, Sep 30, 2020 at 05:53:46PM +0200, Jann Horn via Containers wrote:
> On Wed, Sep 30, 2020 at 1:07 PM Michael Kerrisk (man-pages)
> wrote:
> > I knew it would be a big ask, but below is kind of the manual page
> > I was hoping you might write [1] for the seccomp user-space notification
> >
On Sun, Sep 27, 2020 at 02:24:28PM +0800, Lu Baolu wrote:
> drivers/iommu/intel/iommu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied for v5.9, thanks.
On Thu, Oct 01, 2020 at 02:34:31PM +0200, Schrempf Frieder wrote:
> + pca9450->sd_vsel_gpio = gpiod_get_optional(pca9450->dev, "sd-vsel",
> GPIOD_OUT_HIGH);
We need a patch adding this to the binding document too.
signature.asc
Description: PGP signature
On Thu, Oct 1, 2020 at 2:30 PM Vaibhav Gupta wrote:
>
> The driver calls pci_enable_wake(, false) in pm8001_pci_resume(), and
> there is no corresponding pci_enable_wake(, true) in
> pm8001_pci_suspend(). Either it should do enable-wake the device in
> .suspend() or should not invoke
Hi Jacob,
On Mon, Sep 28, 2020 at 11:40:53AM -0700, Jacob Pan wrote:
> Just wondering if you will be able to take this for v5.10? There hasn't
> been any material changes since we last discussed in LPC. We have VFIO and
> other vSVA patches depending on it.
Queued for v5.10 now, thanks.
Calling pipe2() with O_NOTIFICATION_PIPE could results in memory leaks
in an error path or CONFIG_WATCH_QUEUE=n. Plug them.
unreferenced object 0xc0141114a0d8 (size 992):
comm "trinity-c61", pid 1353192, jiffies 4296255779 (age 25989.560s)
hex dump (first 32 bytes):
80 11 00 00 e8 03
Thu, Oct 01, 2020 at 12:30:18PM CEST, henrik.bjoernl...@microchip.com wrote:
>This is the definition of the CFM switchdev interface.
>
>The interface consist of these objects:
>SWITCHDEV_OBJ_ID_MEP_CFM,
>SWITCHDEV_OBJ_ID_MEP_CONFIG_CFM,
>SWITCHDEV_OBJ_ID_CC_CONFIG_CFM,
>
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: f94c91f7ba3ba7de2bc8aa31be28e1abb22f849e
Gitweb:
https://git.kernel.org/tip/f94c91f7ba3ba7de2bc8aa31be28e1abb22f849e
Author:Libing Zhou
AuthorDate:Thu, 20 Aug 2020 10:56:41 +08:00
Committer:
>>> Also, wrt KASLR stuff, that issue is still seen sometimes but I haven't
>>> had
>>> bandwidth to dive deep into the issue and fix it.
So what's the plan there? You first mentioned this issue early this year
and judged by your response it is not clear whether you will
get_tbu() is redundant with mftbu() and is not used anymore.
Remove it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/time.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 3ef0f4b3299e..c4ea81c966b0
mftbu() is always defined now, so the #ifdef can be removed
and replaced by an IS_ENABLED(CONFIG_PPC64) inside the
PPC32 version of get_tb().
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/time.h | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git
get_tbl() is confusing as it returns the content of TBL register
on PPC32 but the concatenation of TBL and TBU on PPC64.
Use mftb() instead.
Do the same with get_tbu() for consistency allthough it's name
is less confusing.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/delay.h |
On PPC64, we have mftb().
On PPC32, we have mftbl() and an #define mftb() mftbl().
mftb() and mftbl() are equivalent, their purpose is to read the
content of SPRN_TRBL, as returned by 'mftb' simplified instruction.
binutils seems to define 'mftbl' instruction as an equivalent
of 'mftb'.
However
On PPC64, get_tbl() is defined as an alias of get_tb() which return
the result of mftb(). That exactly the same as what the PPC32 version
does. We don't need two versions.
Remove the PPC64 definition of get_tbl() and use the PPC32 version
for both.
Signed-off-by: Christophe Leroy
---
No need to have two versions that are identical.
CONFIG_PPC_CELL is only selected by PPC64 targets.
CONFIG_E500 is the only PPC64 target selecting CONFIG_FSL_BOOK3E.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/reg.h | 14 --
1 file changed, 4 insertions(+), 10
On 01.10.20 14:34, Schrempf Frieder wrote:
From: Frieder Schrempf
In order to use ultra high speed modes (UHS) on the SD card slot, we
add matching pinctrls and fix the voltage switching for LDO5 of the
PMIC, by providing the SD_VSEL pin as GPIO to the PMIC driver.
Signed-off-by: Frieder
[I'm on vacation so I'll just give this a quick glance for now.]
On Wed, Sep 30, 2020 at 01:07:38PM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Tycho, Sargun (and all),
>
> I knew it would be a big ask, but below is kind of the manual page
> I was hoping you might write [1] for the seccomp
> > Can you run 1000Base-X over these links?
> With some reading "1000base-x" does seem the right thing to say here.
> It's even what is reflected in the CMODE field for those ports.
One more thing you might need is
managed = "in-band-status";
> > If you can, it is probably
> > worth chatting
On Wed, Sep 30, 2020 at 10:21:20PM +, Kalesh Singh wrote:
> Android needs to move large memory regions for garbage collection.
> Optimize mremap for >= 1GB-sized regions by moving at the PUD/PGD
> level if the source and destination addresses are PUD-aligned.
> For CONFIG_PGTABLE_LEVELS == 3,
On Thu, Oct 01, 2020 at 05:54:43PM +0530, Vaibhav Gupta wrote:
Linux Kernel Mentee: Remove Legacy Power Management.
The purpose of this patch series is to upgrade power management in SCSI
drivers. This has been done by upgrading .suspend() and .resume() callbacks.
The upgrade makes sure that the
From: Frieder Schrempf
LDO5 has two separate control registers. LDO5CTRL_L is used if the
input signal SD_VSEL is low and LDO5CTRL_H if it is high.
The current driver implementation only uses LDO5CTRL_H. To make this
work on boards that have SD_VSEL connected to a GPIO, we add support
for
From: Frieder Schrempf
In order to use ultra high speed modes (UHS) on the SD card slot, we
add matching pinctrls and fix the voltage switching for LDO5 of the
PMIC, by providing the SD_VSEL pin as GPIO to the PMIC driver.
Signed-off-by: Frieder Schrempf
---
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
The driver calls pci_enable_wake(, false) in mvumi_resume(), and
there is no corresponding pci_enable_wake(, true) in mvumi_suspend().
Either it should do enable-wake the device in .suspend() or should not
invoke pci_enable_wake() at all.
Concluding that this driver doesn't support
There is no "device" parameter in mvumi_shutdown(). Instead there is
"pdev" which is not described.
Signed-off-by: Vaibhav Gupta
---
drivers/scsi/mvumi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/mvumi.c b/drivers/scsi/mvumi.c
index
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
The driver calls pci_enable_wake(, false) in pmcraid_resume(), and
there is no corresponding pci_enable_wake(, true) in pmcraid_suspend().
Either it should do enable-wake the device in .suspend() or should not
invoke pci_enable_wake() at all.
Concluding that this driver doesn't support
The driver calls pci_enable_wake(, false) in twl_resume(), and
there is no corresponding pci_enable_wake(, true) in twl_suspend().
Either it should do enable-wake the device in .suspend() or should not
invoke pci_enable_wake() at all.
Concluding that this driver doesn't support
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
On Thu, Oct 1, 2020 at 1:26 AM Krzysztof Kozlowski wrote:
>
> On Thu, 1 Oct 2020 at 08:22, Stephen Rothwell wrote:
> >
> > Hi all,
> >
> > Today's linux-next merge of the devicetree tree got a conflict in:
> >
> > Documentation/devicetree/bindings/mfd/syscon.yaml
> >
> > between commit:
> >
>
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
The driver calls pci_enable_wake(, false) in twa_resume(), and
there is no corresponding pci_enable_wake(, true) in twa_suspend().
Either it should do enable-wake the device in .suspend() or should not
invoke pci_enable_wake() at all.
Concluding that this driver doesn't support
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
The driver calls pci_enable_wake(, false) in scsih_resume(), and
there is no corresponding pci_enable_wake(, true) in scsih_suspend().
Either it should do enable-wake the device in .suspend() or should not
invoke pci_enable_wake() at all.
Concluding that this driver doesn't support
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
On Wed 30-09-20 21:27:12, Sebastiaan Meijer wrote:
> > yes it shows the bottleneck but it is quite artificial. Read data is
> > usually processed and/or written back and that changes the picture a
> > lot.
> Apologies for reviving an ancient thread (and apologies in advance for my lack
> of
The driver calls pci_enable_wake(, false) in pm8001_pci_resume(), and
there is no corresponding pci_enable_wake(, true) in
pm8001_pci_suspend(). Either it should do enable-wake the device in
.suspend() or should not invoke pci_enable_wake() at all.
Concluding that this driver doesn't
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
The driver calls pci_enable_wake(, false) in hisi_sas_v3_resume(), and
there is no corresponding pci_enable_wake(, true) in
hisi_sas_v3_suspend(). Either it should do enable-wake the device in
.suspend() or should not invoke pci_enable_wake() at all.
Concluding that this driver doesn't
The driver calls pci_enable_wake(, false) in arcmsr_resume(), and
there is no corresponding pci_enable_wake(, true) in arcmsr_suspend().
Either it should do enable-wake the device in .suspend() or should not
invoke pci_enable_wake() at all.
Concluding that this driver doesn't support
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
The driver calls pci_enable_wake(, false) in esas2r_resume(), and
there is no corresponding pci_enable_wake(, true) in esas2r_suspend().
Either it should do enable-wake the device in .suspend() or should not
invoke pci_enable_wake() at all.
Concluding that this driver doesn't support
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
use generic power management
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
The driver calls pci_enable_wake(, false) in aac_resume(), and there is
no corresponding pci_enable_wake(, true) in aac_suspend(). Either it
should do enable-wake the device in .suspend() or should not invoke
pci_enable_wake() at all.
Concluding that this is a bug and PCI core calls
There is no "device" parameter in megasas_shutdown(). Instead there is
"pdev" which is not described.
Signed-off-by: Vaibhav Gupta
---
drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
This is considered bad for the following reasons:
(1) We only support the block protection with BPn bits for write
protection. Not all SST parts support this.
(2) Newly added flash chip will automatically inherit the "has
locking" support and thus needs to explicitly tested. Better
This is considered bad for the following reasons:
(1) We only support the block protection with BPn bits for write
protection. Not all Atmel parts support this.
(2) Newly added flash chip will automatically inherit the "has
locking" support and thus needs to explicitly tested. Better
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to
Linux Kernel Mentee: Remove Legacy Power Management.
The purpose of this patch series is to upgrade power management in
drivers. This has been done by upgrading .suspend() and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not change the
order of
The driver calls pci_enable_wake(, false) in megasas_resume(), and
there is no corresponding pci_enable_wake(, true) in megasas_suspend().
Either it should do enable-wake the device in .suspend() or should not
invoke pci_enable_wake() at all.
Concluding that this driver doesn't support
On Wed, Sep 30, 2020 at 03:42:17PM -0700, Lokesh Gidra wrote:
> On Wed, Sep 30, 2020 at 3:32 PM Kirill A. Shutemov
> wrote:
> >
> > On Wed, Sep 30, 2020 at 10:21:17PM +, Kalesh Singh wrote:
> > > mremap time can be optimized by moving entries at the PMD/PUD level if
> > > the source and
On 25.09.20 18:06, Hui Su wrote:
> 1. the cpuset.c has been moved from kernel/cpuset.c to
> kernel/cgroup/cpuset.c long time ago, but the comment is stale,
> so we update it.
> 2. get_page_from_freelist() may alloc many pages according to
> order, we may use pages for better.
>
> Signed-off-by:
Hi Tudor,
Am 2020-10-01 13:46, schrieb tudor.amba...@microchip.com:
Am 2020-10-01 09:07, schrieb tudor.amba...@microchip.com:
diff --git a/drivers/mtd/spi-nor/core.c
b/drivers/mtd/spi-nor/core.c
index cc68ea84318e..fd1c36d70a13 100644
--- a/drivers/mtd/spi-nor/core.c
+++
Hi,
On Thu, Oct 1, 2020 at 4:38 AM Florian Fainelli wrote:
>
> On 9/30/2020 6:27 PM, Scott Branden wrote:
> > This patch series drops previous patches in [1]
> > that were incorporated by Kees Cook into patch series
> > "Introduce partial kernel_read_file() support" [2].
> >
> > Remaining
On Wed, Sep 30, 2020 at 09:05:23AM +0100, Will Deacon wrote:
> The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b:
>
> Linux 5.9-rc3 (2020-08-30 16:01:54 -0700)
>
> are available in the Git repository at:
>
>
> On Sep 30, 2020, at 9:29 PM, Vinod Koul wrote:
>
> Hi Dave,
>
>> On 30-09-20, 15:19, Dave Jiang wrote:
>>
>>
>>> On 9/24/2020 2:51 PM, Borislav Petkov wrote:
>>> On Thu, Sep 24, 2020 at 02:32:35PM -0700, Dave Jiang wrote:
Hi Vinod,
Looks like we are cleared on the x86 patches
Hi Baolu,
On Tue, Sep 29, 2020 at 08:11:35AM +0800, Lu Baolu wrote:
> I have no preference. It depends on which patch goes first. Let the
> maintainers help here.
No preference on my side, except that it is too late for this now to
make it into v5.10. Besides that I let the decission up to you
On 2020-09-30 15:24, Mauro Carvalho Chehab wrote:
The C domain functions there collide with the English ones,
due to namespace collision, generating lots of warnings with
Sphinx 3.x:
./include/linux/mutex.h:121: WARNING: Duplicate C declaration, also
defined in
On 2020-09-30 15:25, Mauro Carvalho Chehab wrote:
There's a missing "`", causing this warning:
./Documentation/translations/it_IT/kernel-hacking/hacking.rst:404:
WARNING: Unparseable C cross-reference: 'cpu_to_be32p(), che prende un
puntatore\nad un tipo, e ritorna il valore convertito.
From: Frieder Schrempf
Kontron Electronics GmbH offers small and powerful SoMs based on the
i.MX8M Mini SoC including PMIC, LPDDR4-RAM, eMMC and SPI NOR.
The matching baseboards have the same form factor and similar interfaces
as the other boards from the Kontron "Board-Line" family, including
From: Frieder Schrempf
Add entries for the SoMs and boards based on i.MX8MM from Kontron
Electronics GmbH.
Signed-off-by: Frieder Schrempf
Reviewed-by: Rob Herring
---
Changes for v3:
* None
Changes for v2:
* Merge the SoMs and baseboards N8010 and N8011 into a single
configuration
On Wed, Sep 30, 2020 at 5:01 PM Jann Horn wrote:
> Hmm, this won't work, because the task could be exiting, and seccomp
> filters are detached in release_task() (using
> seccomp_filter_release()). And at the moment, seccomp_filter_release()
> just locklessly NULLs out the tsk->seccomp.filter
Commit 7736627b865d ("perf stat: Use affinity for closing file
descriptors") will use FD(evsel, cpu, thread) to read and write
file descriptors xyarray. For a kernel PMU event, this leads to
serious memory corruption and perf crash.
I have seen evlist->core.cpus->nr is 1 while evsel has cpus->nr
On 01/10/20 08:20AM, tudor.amba...@microchip.com wrote:
> On 9/30/20 9:57 PM, Pratyush Yadav wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > From: Tudor Ambarus
> >
> > Parse just the 22nd dword and look for the 'DTR Octal Mode
On Thu, Oct 01, 2020 at 11:40:04AM +0200, Vitaly Kuznetsov wrote:
> Sasha Levin writes:
>
> > cpumask can change underneath us, which is generally safe except when we
> > call into hv_cpu_number_to_vp_number(): if cpumask ends up empty we pass
> > num_cpu_possible() into
Hi all,
In commit
44d59235ace5 ("Bluetooth: hci_h5: close serdev device and free hu in
h5_close")
Fixes tag
Fixes: https://syzkaller.appspot.com/bug?extid=6ce141c55b2f7aafd1c4
has these problem(s):
- No SHA1 recognised
Fixes tags normally refer to the commit that is fixed.
--
901 - 1000 of 1339 matches
Mail list logo
