From: Colin Ian King
An incorrect sizeof is being used, struct attribute ** is not correct,
it should be struct attribute *. Note that since ** is the same size as
* this is not causing any issues. Improve this fix by using sizeof(*attrs)
as this allows us to not even reference the type of the p
Hello,
My Name is Mrs.Maria Abdullah from Wales United Kingdom,
I would like to work with you to carry out a promise i made to
God by willing all that i have to the charity because i am very
sick now (Covid-19 Virus Infection)
Get back to me for more details via my private email.
Email: maria
On 30/09/2020 16.13, Marc Zyngier wrote:
> On 2020-09-30 11:01, Peter Ujfalusi wrote:
>> On 30/09/2020 11.33, Marc Zyngier wrote:
>>> On 2020-09-30 08:45, Peter Ujfalusi wrote:
The DMA (BCDMA/PKTDMA and their rings/flows) events are under the
INTA's
supervision as unmapped events
Hi Stan,
On Thu, Oct 01, 2020 at 01:57:59PM +0300, Stanimir Varbanov wrote:
> Hi Mani,
>
> On 10/1/20 8:57 AM, Manivannan Sadhasivam wrote:
> > Hi Stan,
> >
> > On Thu, Oct 01, 2020 at 12:46:46AM +0300, Stanimir Varbanov wrote:
> >> Hi Mani,
> >>
> >> On 9/30/20 6:09 PM, Manivannan Sadhasivam wr
On 10/1/20 10:38 AM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi Tudor,
Hi, Michael,
>
> 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/
On Wed, Sep 30, 2020 at 09:05:23AM +0100, Will Deacon wrote:
> Please pull these arm-smmu updates for 5.10. Summary in the tag, but the
> big thing here is the long-awaited SVM enablement from Jean-Philippe.
> We're not quite done yet, but this pull extends the SMMUv3 driver so that
> we're very cl
On Wed, Sep 30, 2020 at 5:40 PM Kees Cook wrote:
> I don't want this config: there is only 1 caching mechanism happening
> in this series and I do not want to have it buildable as "off": it
> should be available for all supported architectures. When further caching
> methods happen, the config can
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 hv_cpu_number_to_vp_numbe
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.
--
Cheers
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 E
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
wi
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 point
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 (N801X).
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
S
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. L
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 'translations/it_IT/kernel
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 wh
> 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 fo
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:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.g
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 patches
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
+++ b/drivers/mtd/spi-nor/
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 destin
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: Hu
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 operat
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 ena
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 ha
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 ha
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
pci_en
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
b/driver
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
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 ha
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 ca
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 enabl
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 ha
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 enabl
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 sup
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 ha
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 ha
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 ha
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 knowled
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 suppo
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 enable-
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 ha
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 enable-wake
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 ha
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 ha
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 enable-wake
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 ha
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 ha
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 ena
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 ha
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 enable-
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 6c710585a628..82dd7c37c1
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 ha
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 specify
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
---
.../dts/freescale/imx8mm-kontron-n8
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
> > 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 t
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, m
[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 use
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 Schre
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
---
arch/power
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 delet
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 a/arch/po
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
>>> 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 e
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:
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,
>SWITCHDEV_OB
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 0
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.
Regards,
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 pci_e
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 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 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
> > m
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 in
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 you'll
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, 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 allo
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, 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 in
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
>
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 Ch
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 's390-5.9-6
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 remai
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 account
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 val
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 following
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 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 Schre
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 for
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.
>
> Li
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:
>
> ERR
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.
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
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 Ethe
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
301 - 400 of 1340 matches
Mail list logo
