On Sat, 24 Oct 2020, Joe Perches wrote:
> On Sat, 2020-10-24 at 18:54 +0530, Aditya wrote:
> > > Would you like to work on
> > > further rules that can be improved with your evaluation approach?
> >
> > Yes, I would like work on further rules.
>
> Some generic ideas:
>
> How about working
On Sat, Oct 24, 2020 at 11:59:17AM +0900, Namhyung Kim wrote:
> I found that the UNHALTED_CORE_CYCLES event is only available in the
> Intel machines and it makes other vendors/archs fail on the test. As
> libpfm4 can parse the generic events like cycles, let's use them.
>
> Fixes: 40b74c30ffb9
On my laptop, I have about 31MB allocated to buffer_heads.
buffer_head 182728 299910104 391 : tunables000 :
slabdata 7690 7690 0
Reducing the size of the buffer_head by 8 bytes gets us to 96 bytes,
which means we get 42 per page instead of 39 and saves me
> Subject: [kbuild-all] Re: ld.lld: warning: fs/built-
> in.a(afs/cell.o):(.data..L__unnamed_8) is being placed in
> '.data..L__unnamed_8'
>
> https://github.com/ClangBuiltLinux/linux/issues/1185
sorry for false positive, we will ignore all lld warning related to "being
placed in", the initial
Hi Tushar,
On Wed, 2020-09-23 at 12:20 -0700, Tushar Sugandhi wrote:
> There are several kernel components that contain critical data which if
> accidentally or maliciously altered, can compromise the security of the
> kernel. Example of such components would include LSMs like SELinux, or
>
On Sat, Oct 24, 2020 at 08:41:58PM -0400, Arvind Sankar wrote:
> Hi, I think the definition of BOOT_PGT_SIZE in
> arch/x86/include/asm/boot.h is insufficient, especially after
> ca0e22d4f011 ("x86/boot/compressed/64: Always switch to own page table")
>
> Currently, it allocates 6 pages if KASLR
Greetings
I am Katie Brianna Taylor and I am American soldier attached to the UN
peacekeeping force in Afghanistan. I am the commanding officer of the third
Battalion soldier regime. As you may know, everyday there are several cases of
insurgent attacks and suicide bombs going on here. We
Hello,
syzbot found the following issue on:
HEAD commit:d7691390 Merge tag 'block-5.10-2020-10-24' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=161d04b050
kernel config: https://syzkaller.appspot.com/x/.config?x=65e86ae741289c65
Hello Andy,
On Fri, Oct 23, 2020 at 11:47 PM Luka Kovacic wrote:
>
> Hi Andy,
>
> On Tue, Oct 20, 2020 at 10:59 AM Andy Shevchenko
> wrote:
> >
> > On Tue, Oct 20, 2020 at 1:19 AM Luka Kovacic
> > wrote:
> > >
> > > Add the iEi WT61P803 PUZZLE HWMON driver, that handles the fan speed
> > >
Add initial support for the IEI Puzzle-M801 1U Rackmount Network
Appliance board.
The board is based on the quad-core Marvell Armada 8040 SoC and supports
up to 16 GB of DDR4 2400 MHz ECC RAM. It has a PCIe x16 slot (x2 lanes
only) and an M.2 type B slot.
Main system hardware:
2x USB 3.0
4x
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d76913908102044f14381df865bb74df17a538cb
commit: 555782aa556af869d4f390996607abd356513ba4 cifs: move smb version mount
options into fs_context.c
date: 2 days ago
config: powerpc64-randconfig-r004-20201022
Add the IEI WT61P803 PUZZLE HWMON driver, that handles the fan speed
control via PWM, reading fan speed and reading on-board temperature
sensors.
The driver registers a HWMON device and a simple thermal cooling device to
enable in-kernel fan management.
This driver depends on the IEI WT61P803
Add the iei-wt61p803-puzzle driver sysfs interface documentation to allow
monitoring and control of the microcontroller from user space.
Signed-off-by: Luka Kovacic
Cc: Luka Perkov
Cc: Robert Marko
---
.../testing/sysfs-driver-iei-wt61p803-puzzle | 55 +++
1 file changed, 55
Add support for the IEI WT61P803 PUZZLE LED driver.
Currently only the front panel power LED is supported,
since it is the only LED on this board wired through the
MCU.
The LED is wired directly to the on-board MCU controller
and is toggled using an MCU command.
Support for more LEDs is going to
Add a driver for the IEI WT61P803 PUZZLE microcontroller, used in some
IEI Puzzle series devices. The microcontroller controls system power,
temperature sensors, fans and LEDs.
This driver implements the core functionality for device communication
over the system serial (serdev bus). It handles
This patchset adds support for the IEI WT61P803 PUZZLE microcontroller,
which enables some board specific features like fan and LED control,
system power management and temperature sensor reading on some IEI
Puzzle series boards.
The first board to use this functionality is IEI Puzzle-M801 1U
Add an entry for the IEI WT61P803 PUZZLE driver (MFD, HWMON, LED drivers).
Signed-off-by: Luka Kovacic
Cc: Luka Perkov
Cc: Robert Marko
---
MAINTAINERS | 14 ++
1 file changed, 14 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 867157311dc8..d56fdc300066 100644
---
Add the IEI WT61P803 PUZZLE Device Tree bindings for MFD, HWMON and LED
drivers. A new vendor prefix is also added accordingly for
IEI Integration Corp.
Signed-off-by: Luka Kovacic
Cc: Luka Perkov
Cc: Robert Marko
---
.../hwmon/iei,wt61p803-puzzle-hwmon.yaml | 53
Hi, I think the definition of BOOT_PGT_SIZE in
arch/x86/include/asm/boot.h is insufficient, especially after
ca0e22d4f011 ("x86/boot/compressed/64: Always switch to own page table")
Currently, it allocates 6 pages if KASLR is disabled, and either 17 or
19 pages depending on X86_VERBOSE_BOOTUP
Hi Thomas,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d76913908102044f14381df865bb74df17a538cb
commit: 7505576d1c1ac0cfe85fdf90999433dd8b673012 MIPS: add support for SGI
Octane (IP30)
date: 12 months ago
The huge page could be mapped through multiple contiguous PMDs or PTEs.
The corresponding huge page sizes aren't supported by the page table
walker currently.
This fails the unsupported huge page sizes to the near one. Otherwise,
the guest can't boot successfully: CONT_PMD_SHIFT and
Guest fails to boot when the memory is backed up by hugetlbfs regions,
which correspond to contiguous PMDs or PTEs. For example, the guest
fails to boot when its memory is backed up by 64KB hugetlbfs pages.
The first two patches are sorts of cleanup, not introducing any logical
changes. The last
The 52-bits physical address is disabled until CONFIG_ARM64_PA_BITS_52
is chosen. This uses option for that check, to avoid the unconditional
check on PAGE_SHIFT in the hot path and thus save some CPU cycles.
Signed-off-by: Gavin Shan
---
arch/arm64/kvm/hyp/pgtable.c | 10 ++
1 file
PUD huge page isn't available when CONFIG_ARM64_4K_PAGES is disabled.
In this case, we needn't try to map the memory through PUD huge pages
to save some CPU cycles in the hot path.
This also corrects the code style issue, which was introduced by
commit <523b3999e5f6> ("KVM: arm64: Try PMD block
After a loss of tranport due to an adatper migration or crash/disconnect from
the host partner there is a tiny window where we can race adjusting the
request_limit of the adapter. The request limit is atomically inc/dec to track
the number of inflight requests against the allowed limit of our VIOS
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d76913908102044f14381df865bb74df17a538cb
commit: 0809ae724904c3c5dbdddf4169d48aac9c6fcdc8 irqchip/bcm2836: Configure
mailbox interrupts as standard interrupts
date: 5 weeks ago
config:
On 2020/10/24 20:27, Vineeth Pillai wrote:
>
>
> On 10/24/20 7:10 AM, Vineeth Pillai wrote:
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 93a3b874077d..4cae5ac48b60 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -4428,12 +4428,14 @@
On 10/24/20 4:21 PM, Joe Perches wrote:
>> +if (exists($attr_list{$curr_attr})) {
>> +my $new = $attr_list{$curr_attr};
>> +WARN("PREFER_DEFINED_ATTRIBUTE_MACRO",
>> +
On Sat, 2020-10-24 at 14:35 +0530, Dwaipayan Ray wrote:
> It is generally preferred that the macros from
> include/linux/compiler_attributes.h are used, unless there
> is a reason not to.
>
> checkpatch currently checks __attribute__ for each of
> packed, aligned, printf, scanf, and weak. Other
Instead of periodically resetting watchdogs from thread context,
this patch simply forces resched and checks rq->sched_count.
Watchdog is reset if the sched count increases. If the same thread
is picked by pick_next_task during resched, there is no context
switch.
With the new method we lose
Instead of periodically resetting watchdogs from thread context,
this patch simply forces resched and checks rq->sched_count.
Watchdog is reset if the sched count increases. If the same thread
is picked by pick_next_task during resched, there is no context
switch.
With the new method we lose
Hi Laurent
On 24/10/2020 23:36, Laurent Pinchart wrote:
> Hi Dan,
>
> On Sat, Oct 24, 2020 at 11:28:06PM +0100, Daniel Scally wrote:
>> On 24/10/2020 10:37, Laurent Pinchart wrote:
>>
> I wonder if we could avoid depending on the I2C device being created by
> getting the fwnode from adev,
Hi Dan,
On Sat, Oct 24, 2020 at 11:28:06PM +0100, Daniel Scally wrote:
> On 24/10/2020 10:37, Laurent Pinchart wrote:
> >
> >>> I wonder if we could avoid depending on the I2C device being created by
> >>> getting the fwnode from adev, and setting ->secondary manually. adev
> >>> would need to be
Hi Laurent
On 24/10/2020 10:37, Laurent Pinchart wrote:
>
>>> I wonder if we could avoid depending on the I2C device being created by
>>> getting the fwnode from adev, and setting ->secondary manually. adev
>>> would need to be passed to get_acpi_ssdb_sensor_data() instead of dev.
>> Let me try
Thanks Mauro, small fix for iser
On 10/23/2020 7:33 PM, Mauro Carvalho Chehab wrote:
Some functions have different names between their prototypes
and the kernel-doc markup.
Others need to be fixed, as kernel-doc markups should use this format:
identifier - description
Signed-off-by:
From: Thomas Gleixner
The ioapic interrupt type table is wrong as it assumes that polarity in
IO/APIC context means active high when set. But the IO/APIC polarity is
working the other way round. This works because the ordering of the entries
is consistent with the device tree and the type
Fix the conditions for enabling x2apic on guests without interrupt
remapping, and support 15-bit Extended Destination ID to allow 32768
CPUs without IR on hypervisors that support it.
Make the I/OAPIC code generate its RTE directly from the MSI message
created by the parent irqchip, and fix
From: Thomas Gleixner
The UV x2apic is strictly using physical destination mode, but
apic::dest_logical is initialized with APIC_DEST_LOGICAL.
This does not matter much because UV does not use any of the generic
functions which use apic::dest_logical, but is still inconsistent.
Signed-off-by:
From: David Woodhouse
The Intel IOMMU has an MSI-like configuration for its interrupt, but it
isn't really MSI. So it gets to abuse the high 32 bits of the address, and
puts the high 24 bits of the extended APIC ID there.
This isn't something that can be used in the general case for real MSIs,
From: Thomas Gleixner
Architectures like x86 have their MSI messages in various bits of the data,
address_lo and address_hi field. Composing or decomposing these messages
with bitmasks and shifts is possible, but unreadable gunk.
Allow architectures to provide an architecture specific
From: Thomas Gleixner
All these functions are only used for logical destination mode. So reading
the destination mode mask from the apic structure is a pointless
exercise. Just hand in the proper constant: APIC_DEST_LOGICAL.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
From: David Woodhouse
This shouldn't be dependent on PCI_MSI. HPET and I/O-APIC can deliver
interrupts through MSI without having any PCI in the system at all.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/apic.h | 8 +++-
From: David Woodhouse
Currently, Linux as a hypervisor guest will enable x2apic only if there are
no CPUs present at boot time with an APIC ID above 255.
Hotplugging a CPU later with a higher APIC ID would result in a CPU which
cannot be targeted by external interrupts.
Add a filter in
From: Thomas Gleixner
Use the bitfields in the x86 shadow structs instead of decomposing the
32bit value with macros.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/kvm/irq_comm.c | 31 +--
1 file changed, 13 insertions(+), 18
From: Thomas Gleixner
apic::irq_dest_mode is actually a boolean, but defined as u32 and named in
a way which does not explain what it means.
Make it a boolean and rename it to 'dest_mode_logical'
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/apic.h
From: Thomas Gleixner
Create shadow structs with named bitfields for msi_msg data, address_lo and
address_hi and use them in the MSI message composer.
Provide a function to retrieve the destination ID. This could be inline,
but that'd create a circular header dependency.
[dwmw2: fix bitfields
From: David Woodhouse
All possible parent domains have a select method now. Make use of it.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/io_apic.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git
From: Thomas Gleixner
The enum ioapic_irq_destination_types and the enumerated constants starting
with 'dest_' are gross misnomers because they describe the delivery mode.
Rename then enum and the constants so they actually make sense.
Signed-off-by: Thomas Gleixner
Signed-off-by: David
From: David Woodhouse
This isn't really dependent on PCI MSI; it's just generic MSI which is now
supported by the generic x86_vector_domain. Move the HPET MSI support back
into hpet.c with the rest of the HPET support.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
From: David Woodhouse
Prerequesite to make x86 more irqdomain compliant.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
kernel/irq/irqdomain.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
From: Thomas Gleixner
Use the x86 shadow structs in msi_msg instead of the macros.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
drivers/pci/controller/vmd.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/vmd.c
From: Thomas Gleixner
Use the bitfields in the x86 shadow struct to compose the MSI message.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
drivers/iommu/intel/irq_remapping.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git
From: David Woodhouse
Preparatory change to remove irq_remapping_get_irq_domain().
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
drivers/iommu/amd/iommu.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/iommu/amd/iommu.c
From: Thomas Gleixner
Use the msi_msg shadow structs and compose the message with named bitfields
instead of the unreadable macro maze.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/pci/xen.c | 26 +++---
1 file changed, 11 insertions(+), 15
From: David Woodhouse
The I/O-APIC generates an MSI cycle with address/data bits taken from its
Redirection Table Entry in some combination which used to make sense, but
now is just a bunch of bits which get passed through in some seemingly
arbitrary order.
Instead of making IRQ remapping
From: David Woodhouse
Now that the old get_irq_domain() method has gone, consolidate on just the
map_XXX_to_iommu() functions.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
drivers/iommu/intel/irq_remapping.c | 19 +++
1 file changed, 7 insertions(+), 12
From: David Woodhouse
Bits 63-48 of the I/OAPIC Redirection Table Entry map directly to bits 19-4
of the address used in the resulting MSI cycle.
Historically, the x86 MSI format only used the top 8 of those 16 bits as
the destination APIC ID, and the "Extended Destination ID" in the lower 8
From: Thomas Gleixner
Having two seperate structs for the I/O-APIC RTE entries (non-remapped and
DMAR remapped) requires type casts and makes it hard to map.
Combine them in IO_APIC_routing_entry by defining a union of two 64bit
bitfields. Use naming which reflects which bits are shared and
From: Thomas Gleixner
Nothing uses the macro maze anymore.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
arch/x86/include/asm/msidef.h | 57 ---
1 file changed, 57 deletions(-)
delete mode 100644 arch/x86/include/asm/msidef.h
diff --git
From: David Woodhouse
Preparatory for removing irq_remapping_get_irq_domain()
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
drivers/iommu/hyperv-iommu.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iommu/hyperv-iommu.c
From: David Woodhouse
All users are converted to use the fwspec based parent domain lookup.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h| 2 --
arch/x86/include/asm/irq_remapping.h | 9
drivers/iommu/amd/iommu.c
From: David Woodhouse
Preparatory for removing irq_remapping_get_irq_domain()
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
drivers/iommu/intel/irq_remapping.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/iommu/intel/irq_remapping.c
From: Thomas Gleixner
struct apic has two members which store information about the destination
mode: dest_logical and irq_dest_mode.
dest_logical contains a mask which was historically used to set the
destination mode in IPI messages. Over time the usage was reduced and the
logical/physical
From: David Woodhouse
This will be used to select the irqdomain for I/O-APIC and HPET.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/irqdomain.h | 3 +++
arch/x86/kernel/apic/vector.c| 43
2 files changed, 46
From: Thomas Gleixner
Get rid of the macro mess and use the shadow structs for the x86 specific
MSI message format. Convert the intcapxt setup to use named bitfields as
well while touching it anyway.
Signed-off-by: Thomas Gleixner
Signed-off-by: David Woodhouse
---
drivers/iommu/amd/init.c
From: Thomas Gleixner
'trigger' and 'polarity' are used throughout the I/O-APIC code for handling
the trigger type (edge/level) and the active low/high configuration. While
there are defines for initializing these variables and struct members, they
are not used consequently and the meaning of
From: David Woodhouse
This allows the host to indicate that MSI emulation supports 15-bit
destination IDs, allowing up to 32768 CPUs without interrupt remapping.
cf. https://patchwork.kernel.org/patch/11816693/ for qemu
Signed-off-by: David Woodhouse
Acked-by: Paolo Bonzini
---
From: David Woodhouse
All possible parent domains have a select method now. Make use of it.
Signed-off-by: David Woodhouse
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/hpet.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git
From: David Woodhouse
No functional change; just reserve the feature bit for now so that VMMs
can start to implement it.
This will allow the host to indicate that MSI emulation supports 15-bit
destination IDs, allowing up to 32768 CPUs without interrupt remapping.
cf.
From: David Woodhouse
Some hypervisors can allow the guest to use the Extended Destination ID
field in the MSI address to address up to 32768 CPUs.
This applies to all downstream devices which generate MSI cycles,
including HPET, I/OAPIC and PCI MSI.
HPET and PCI MSI use the same
From: David Woodhouse
If the 15-bit APIC ID support is present in emulated MSI then there's no
need for the pseudo-remapping support.
Signed-off-by: David Woodhouse
---
drivers/iommu/hyperv-iommu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/hyperv-iommu.c
Good Day,
I know this email might come as a surprise to you considering the number of
junk emails we all receive on a daily basis. I can assure you that this email
is authentic and I would appreciate it if the content of this letter is kept
strictly confidential and respects the integrity of
From: Arnd Bergmann
> Sent: 24 October 2020 20:21
> To: harshal chaudhari
> Cc: David Laight ; Greg KH
> ; Sudip Mukherjee
> ; linux-kernel
> Subject: Re: [PATCH] char: ppdev: check if ioctl argument is present and valid
>
> On Sat, Oct 24, 2020 at 5:54 PM harshal chaudhari
> wrote:
> > On
From: Segher Boessenkool
> Sent: 24 October 2020 18:29
>
> On Fri, Oct 23, 2020 at 09:28:59PM +, David Laight wrote:
> > From: Segher Boessenkool
> > > Sent: 23 October 2020 19:27
> > > On Fri, Oct 23, 2020 at 06:58:57PM +0100, Al Viro wrote:
> > > > On Fri, Oct 23, 2020 at 03:09:30PM +0200,
On Fri, Oct 09, 2020 at 10:57:42AM -0600, Brigham Campbell wrote:
> The following patch is a bug fix for an issue introduced by commit
> abe60a3a7afb4058278864aa18c5faf62094c11a which removed the deprecated
> device tree skeletons.
>
> For the devices corresponding to these device trees, an
On Sat, Oct 24, 2020 at 3:23 PM Abel Vesa wrote:
>
> On 20-10-24 11:20:12, Adam Ford wrote:
> > There are some less-documented registers which control clocks and
> > resets for the multimedia block which controls the LCDIF, ISI, MIPI
> > CSI, and MIPI DSI.
> >
> > The i.Mx8M Nano appears to have
Hello,
# Intro
Pardon my tardiness in reporting this, I was stalling my disk upgrade to
help test a fix for a reiserfs problem. I needed to get my life going
again before taking the time to report this.
This is a heads up for a serious problem. I no longer use reiser4
anymore because I can't have
On Sat, Oct 24, 2020 at 10:36:36AM -0700, Tom Rix wrote:
>
> On 10/24/20 9:39 AM, Andrew Lunn wrote:
> > On Sat, Oct 24, 2020 at 08:03:51AM -0700, Tom Rix wrote:
> >> On 10/23/20 1:45 AM, Xu Yilun wrote:
> >>> This driver supports the ethernet retimers (Parkvale) for the Intel PAC
> >>>
On 24/10/2020 16:14, Sakari Ailus wrote:
> Hi Daniel,
>
> Thanks for the update.
Thanks for the comments as always
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Author: Dan Scally
> /* Author: ... */
>
> But not the SPDX tag.
Weird - okedokey
>> +#include
>> +#include
>> +#include
>>
On 20-10-24 11:20:12, Adam Ford wrote:
> There are some less-documented registers which control clocks and
> resets for the multimedia block which controls the LCDIF, ISI, MIPI
> CSI, and MIPI DSI.
>
> The i.Mx8M Nano appears to have a subset of the i.MX8MP registers with
> a couple shared
On Sat, Oct 24, 2020 at 08:47:28AM -0700, Andy Lutomirski wrote:
> On Sat, Oct 24, 2020 at 4:34 AM Jarkko Sakkinen wrote:
> >
> > On Fri, Oct 23, 2020 at 07:19:05AM -0700, Dave Hansen wrote:
> > > On 10/23/20 3:17 AM, Jarkko Sakkinen wrote:
> > > > On Tue, Oct 20, 2020 at 02:19:26PM -0700, Dave
On Sat, Oct 24, 2020 at 2:36 PM Dwaipayan Ray wrote:
>
> It is generally preferred that the macros from
> include/linux/compiler_attributes.h are used, unless there
> is a reason not to.
>
> checkpatch currently checks __attribute__ for each of
> packed, aligned, printf, scanf, and weak. Other
On Sun, Oct 25, 2020 at 12:51 AM Arnd Bergmann wrote:
>
> On Sat, Oct 24, 2020 at 5:54 PM harshal chaudhari
> wrote:
> > On Tue, Oct 13, 2020 at 4:42 PM David Laight
> > wrote:
>
> > So I am a little bit confused about this check whether it's required or not
> > Please could you point me in
On Sat, Oct 24, 2020 at 07:09:53PM +0100, Russell King - ARM Linux admin wrote:
> On Sat, Oct 24, 2020 at 07:17:05PM +0200, Andrew Lunn wrote:
> > > - Every PHY driver gains a .handle_interrupt() implementation that, for
> > > the most part, would look like below:
> > >
> > > irq_status =
The MT6392 is a regulator found on boards based on the MediaTek
MT8167, MT8516, and probably other SoCs. It is a so called PMIC and
connectcts as a slave to a SoC using SPI, wrapped inside PWRAP.
Signed-off-by: Fabien Parent
---
V5:
* Removed unneeded code
* Fix indentation
Add binding documentation of the regulator for MT6392 SoCs.
Signed-off-by: Fabien Parent
Reviewed-by: Rob Herring
---
v5:
* No change
v4:
* No change
v3:
* No change
v2:
* Use 'pmic' as node name for the pmic.
* Use 'regulators' as node name for the
On Sun, Oct 25, 2020 at 12:25:15AM +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> The Ethernet PHY on the Bananapi M64 has the RX and TX delays
> enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins.
>
> Fix the phy-mode description to correct reflect this so that the
>
The pull request you sent on Sat, 24 Oct 2020 09:13:29 -0600:
> git://git.kernel.dk/linux-block.git tags/libata-5.10-2020-10-24
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cb6b2897b9b425433ae31dc01f4e1d549f0028c8
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Sat, 24 Oct 2020 09:13:33 -0600:
> git://git.kernel.dk/linux-block.git tags/io_uring-5.10-2020-10-24
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/af0041875ce7f5a05362b884e90cf82c27876096
Thank you!
--
Deet-doot-dot, I am a bot.
Given that this code is new, let's add a selftest for it as well.
It doesn't rely on fixed sets, instead it picks 1024 numbers and
verifies that they're not more correlated than desired.
Link: https://lore.kernel.org/netdev/20200808152628.ga27...@sdf.org/
Cc: George Spelvin
Cc: Amit Klein
Cc:
From: George Spelvin
Non-cryptographic PRNGs may have great statistical properties, but
are usually trivially predictable to someone who knows the algorithm,
given a small sample of their output. An LFSR like prandom_u32() is
particularly simple, even if the sample is widely scattered bits.
It
With the removal of the interrupt perturbations in previous random32
change (random32: make prandom_u32() output unpredictable), the PRNG
has become 100% deterministic again. While SipHash is expected to be
way more robust against brute force than the previous Tausworthe LFSR,
there's still the
y on arm64.
The whole discussion around this is archived here:
https://lore.kernel.org/netdev/20200808152628.ga27...@sdf.org/
The code is also available for you to pull at:
git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/prandom.git
tags/20201024-v4-5.10
---
v4:
- access noise using ra
The pull request you sent on Sat, 24 Oct 2020 19:46:56 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0eac1102e94807023e57d032bbba51830928b78e
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Sat, 24 Oct 2020 11:23:23 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> tags/x86_seves_fixes_for_v5.10_rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c51ae1247262d4b19451ded1107d9b1b69c57541
Thank you!
--
The pull request you sent on Sat, 24 Oct 2020 16:19:35 +0200:
> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.10-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1b307ac87075c3207c345822ea276fe4f28481d7
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Sat, 24 Oct 2020 05:01:57 -0400:
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9bf8d8bcf3cebe44863188f1f2d822214e84f5b1
Thank you!
--
Deet-doot-dot, I am a bot.
:
Merge tag 'xfs-5.10-merge-7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
(2020-10-23 17:15:06 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/prandom.git
tags/20201024-v4-5.10
for you to fetch changes up
International Monetary Fund (IMF)
Office of the Special Representative to the UN.
Head quarters,
Attn: Beneficiary,
This is to intimate you of a very important information which will be of great
help to redeem you from all the difficulties you have been experiencing in
getting your long
On Sat, Oct 24, 2020 at 07:39:47AM +, Peng Fan wrote:
> > Subject: Re: [PATCH 1/2] i2c: imx: use devm_request_threaded_irq to simplify
> > code
> >
> > On Fri, 23 Oct 2020 at 10:27, wrote:
> > >
> > > From: Peng Fan
> > >
> > > Use devm_request_threaded_irq to simplify code
> > >
> > >
1 - 100 of 276 matches
Mail list logo
