On 6/5/20 6:20 PM, Laurent Vivier wrote:
Le 28/01/2020 à 14:25, Laurent Vivier a écrit :
It can be useful to the interpreter to know which flags are in use.
For instance, knowing if the preserve-argv[0] is in use would
allow to skip the pathname argument.
This patch uses an unused auxiliary
On Fri, Feb 12, 2021 at 05:43:40PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Feb 11, 2021 at 03:38:51PM +0200, James Clark escreveu:
> > From: Leo Yan
> >
> > This patch is to enable sample type PERF_SAMPLE_DATA_SRC for Arm SPE in
> > the perf data, when output the tracing data, it tells
On Wed Feb 10 at 16:01:18 CET 2021, Maxime Ripard wrote:
> Unfortunately we can't take this patch as is, this needs to be your real
> name, see:
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
Dear Maxime,
Thank you very much for
On Sat, Feb 13, 2021 at 2:57 AM Shakeel Butt wrote:
>
> CCing more folks.
>
> On Fri, Feb 12, 2021 at 9:14 AM Muchun Song wrote:
> >
> > The swap charges the actual number of swap entries on cgroup v2.
> > If a swap cache page is charged successful, and then we uncharge
> > the swap counter. It
From: Vincent Cheng
Removed unused header declarations.
Signed-off-by: Vincent Cheng
---
drivers/ptp/ptp_clockmatrix.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/ptp/ptp_clockmatrix.h b/drivers/ptp/ptp_clockmatrix.h
index 0233236..fb32327 100644
---
From: Vincent Cheng
Part of the device initialization aligns the rising edge of the output
clock to the internal 1 PPS clock. If the system APLL and DPLL is not
locked, then the alignment will fail and there will be a fixed offset
between the internal 1 PPS clock and the output clock.
After
From: Vincent Cheng
This series fixes a race condition that may result in the output clock
not aligned to internal 1 PPS clock.
Part of device initialization is to align the rising edge of output
clocks to the internal rising edge of the 1 PPS clock. If the system
APLL and DPLL are not locked
From: Vincent Cheng
When enabling output using PTP_CLK_REQ_PEROUT, need to align the output
clock to the internal 1 PPS clock.
Signed-off-by: Vincent Cheng
Acked-by: Richard Cochran
---
drivers/ptp/ptp_clockmatrix.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
gcc version: 11.0.0 20210208 (experimental) (GCC)
Following build error on arm64:
...
In function ‘printf’,
inlined from ‘regs_dump__printf’ at util/session.c:1141:3,
inlined from ‘regs__printf’ at util/session.c:1169:2:
/usr/include/aarch64-linux-gnu/bits/stdio2.h:107:10: \
error:
In arch/x86/entry/syscall_x32.c, the macros are mapped to symbols
as follows:
__SYSCALL_COMMON(nr, sym) --> __x64_
__SYSCALL_X32(nr, sym) --> __x32_
Originally, the syscalls in the x32 special range (512-547) were all
compat.
This assumption is now broken after the following commits:
Building kernel/sys_ni.c with W=1 emits tons of -Wmissing-prototypes
warnings.
$ make W=1 kernel/sys_ni.o
[ snip ]
CC kernel/sys_ni.o
In file included from kernel/sys_ni.c:10:
./arch/x86/include/asm/syscall_wrapper.h:83:14: warning: no previous prototype
for '__x64_sys_io_setup'
On Sat, Feb 13, 2021 at 12:12 AM Mickaël Salaün wrote:
>
> Could you please push this patch to Linus? Thanks.
>
> On 04/02/2021 15:16, Mickaël Salaün wrote:
> >
> > On 28/01/2021 01:50, Masahiro Yamada wrote:
> >> Building kernel/sys_ni.c with W=1 omits tons of -Wmissing-prototypes
> >> warnings.
On Sat, Feb 13, 2021 at 1:29 AM Sasha Levin wrote:
>
> Instead of storing the version in a single integer and having various
> kernel (and userspace) code how it's constructed, export individual
> (major, patchlevel, sublevel) components and simplify kernel code that
> uses it.
>
> This should
On Fri, Feb 12, 2021 at 10:31:40AM EST, Richard Cochran wrote:
>On Thu, Feb 11, 2021 at 11:38:44PM -0500, vincent.cheng...@renesas.com wrote:
>
>> +static int wait_for_sys_apll_dpll_lock(struct idtcm *idtcm)
>> +{
>> +char *fmt = "%d ms SYS lock timeout: APLL Loss Lock %d DPLL state %d";
>
> -Original Message-
> From: Arnaldo Carvalho de Melo
> Sent: Saturday, February 13, 2021 5:34 AM
> To: Jianlin Lv
> Cc: pet...@infradead.org; mi...@redhat.com; Mark Rutland
> ; alexander.shish...@linux.intel.com;
> jo...@redhat.com; namhy...@kernel.org; nat...@kernel.org;
>
Ignore this patch, I am working on a better one.
On Wed, 2021-01-13 at 22:34 +0500, Ivan Mironov wrote:
> There are clones of DualShock 4 that are very similar to the originals,
> except of 1) they do not support HID feature report 0x81 and 2) they do
> not have any USB Audio interfaces despite
This patch series cleans up the brcmphy.h header and its numerous unused
phydev->dev_flags, fixes the RXC/TXC clock disabling bit and allows the
BCM54210E PHY to utilize APD.
Changes in v2:
- dropped the patch that attempted to fix a possible discrepancy between
the datasheet and the actual
We have a number of unused flags defined today and since we are scarce
on space and may need to introduce new flags in the future remove and
shift every existing flag down into a contiguous assignment.
PHY_BCM_FLAGS_MODE_1000BX was only used internally for the BCM54616S
PHY, so we allocate a
BCM54210E/BCM50212E has been verified to work correctly with the
auto-power down configuration done by bcm54xx_adjust_rxrefclk(), add it
to the list of PHYs working.
While we are at it, provide an appropriate name for the bit we are
changing which disables the RXC and TXC during auto-power down
Avoid a forward declaration by moving the callers of
bcm54xx_config_clock_delay() below its body.
Signed-off-by: Florian Fainelli
---
drivers/net/phy/broadcom.c | 74 +++---
1 file changed, 36 insertions(+), 38 deletions(-)
diff --git
On 2/12/2021 5:14 PM, Florian Fainelli wrote:
>
>
> On 2/12/2021 5:11 PM, Vladimir Oltean wrote:
>> On Fri, Feb 12, 2021 at 12:57:20PM -0800, Florian Fainelli wrote:
>>> When support for optionally disabling the TXC was introduced, bit 2 was
>>> used to do that operation but the datasheet for
On 2/11/21 11:18 AM, Asutosh Das wrote:
> +static inline bool is_rpmb_wlun(struct scsi_device *sdev)
> +{
> + return (sdev->lun == ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLUN));
> +}
> +
> +static inline bool is_device_wlun(struct scsi_device *sdev)
> +{
> + return (sdev->lun ==
> +
On Thu, Feb 11, 2021 at 04:01:44PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.16 release.
> There are 54 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Thu, Feb 11, 2021 at 04:02:23PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.98 release.
> There are 24 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Fri, Feb 12, 2021 at 08:55:04AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.176 release.
> There are 27 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
-base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Guido-G-nther/usb-typec-tps6598x-Add-IRQ-flag-and-register-tracing/20210212-200855
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: openrisc-randconfig
Hi all,
On Fri, 12 Feb 2021 08:30:27 -0700 Jens Axboe wrote:
>
> On 2/12/21 8:18 AM, Frederic Weisbecker wrote:
> > On Thu, Feb 11, 2021 at 04:48:52PM +1100, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Today's linux-next merge of the rcu tree got conflicts in:
> >>
> >>
Hi Mihai,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linux/master]
[also build test ERROR on soc/for-next linus/master v5.11-rc7]
[cannot apply to char-misc/char-misc-testing next-20210211]
[If your patch is applied to the wrong git tree, kindly drop us a note.
Hi Mark,
On Fri, 12 Feb 2021 12:27:59 + Mark Brown wrote:
>
> On Fri, Feb 12, 2021 at 03:31:42PM +1100, Stephen Rothwell wrote:
>
> > BTW Mark: the author's address in 258ea99fe25a uses a non existent domain
> > :-(
>
> Ugh, I think that's something gone wrong with b4 :( A bit late now
On Thu, Feb 11, 2021 at 09:18:03AM -0800, Sean Christopherson wrote:
> On Tue, Feb 09, 2021, Yang Weijiang wrote:
> > When L2 guest status has been changed by L1 QEMU/KVM, sync the change back
> > to L2 guest before the later's next vm-entry. On the other hand, if it's
> > changed due to L2 guest,
On (21/02/12 10:47), Petr Mladek wrote:
> > Fixes: 896fbe20b4e2333fb55 ("printk: use the lockless ringbuffer")
> > Reported-by: kernel test robot
> > Reported-by: J. Avila
> > Signed-off-by: John Ogness
>
> Reviewed-by: Petr Mladek
>
> I am going to push the patch later today. I would prefer
On 2/12/21 7:05 PM, Alexander Duyck wrote:
On Fri, Feb 12, 2021 at 6:40 AM Alex Elder wrote:
Introduce a new function to abstract the knowledge of whether hashed
routing and filter tables are supported for a given IPA instance.
IPA v4.2 is the only one that doesn't support hashed tables (now
On Fri, Feb 12, 2021 at 5:08 PM Stefan Metzmacher wrote:
>
> > Zen 2 seems to have fixed things (knock wood - it's certainly working
> > for me), But many people obviously never saw any issues with Zen 1
> > either.
>
> Do you know about the Zen3 status, I was thinking to replace the system
> by
Memory hotplug may fail on systems with CONFIG_RANDOMIZE_BASE because the
linear map range is not checked correctly.
The start physical address that linear map covers can be actually at the
end of the range because of randmomization. Check that and if so reduce it
to 0.
This can be verified on
On Thu, Feb 04, 2021 at 01:19:47PM +0800, Xing Zhengjun wrote:
>
>
> On 2/3/2021 10:49 AM, Roman Gushchin wrote:
> > On Tue, Feb 02, 2021 at 04:18:27PM +0800, Xing, Zhengjun wrote:
> > > On 1/14/2021 11:18 AM, Roman Gushchin wrote:
> > > > On Thu, Jan 14, 2021 at 10:51:51AM +0800, kernel test
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Fri, 12 Feb 2021 17:15:50 +0200 you wrote:
> From: Vladimir Oltean
>
> The initial goal of this series was to have better support for
> standalone ports mode on the DSA drivers like ocelot/felix and sja1105.
> This
On 2/9/21 11:54 PM, Miaohe Lin wrote:
> If there is no reservation corresponding to a vma, map_chg is always != 0,
> i.e. we can not meet the condition where a vma does not have reservation
> while map_chg = 0.
This commit message might be easier to understand?
vma_resv_map(vma) checks if a
On 2/12/2021 5:14 PM, Vladimir Oltean wrote:
> On Fri, Feb 12, 2021 at 05:08:58PM -0800, Florian Fainelli wrote:
>> That's right, tg3 drove a lot of the Broadcom PHY driver changes back
>> then, I also would like to rework the way we pass flags towards PHY
>> drivers because tg3 is basically
Commit 79edff12060f ("scripts/dtc: Update to upstream version
v1.6.0-51-g183df9e9c2b9") broke booting on Microblaze systems depending on
the build. The problem is libfdt gained an 8-byte starting alignment check,
but the Microblaze built-in DTB area is only 4-byte aligned. This affected
not just
On Fri, Feb 12, 2021 at 05:08:58PM -0800, Florian Fainelli wrote:
> That's right, tg3 drove a lot of the Broadcom PHY driver changes back
> then, I also would like to rework the way we pass flags towards PHY
> drivers because tg3 is basically the only driver doing it right, where
> it checks the
On 2/12/2021 5:11 PM, Vladimir Oltean wrote:
> On Fri, Feb 12, 2021 at 12:57:20PM -0800, Florian Fainelli wrote:
>> When support for optionally disabling the TXC was introduced, bit 2 was
>> used to do that operation but the datasheet for 50610M from 2009 does
>> not show bit 2 as being
On Fri, Feb 12, 2021 at 12:57:20PM -0800, Florian Fainelli wrote:
> When support for optionally disabling the TXC was introduced, bit 2 was
> used to do that operation but the datasheet for 50610M from 2009 does
> not show bit 2 as being defined. Bit 8 is the one that allows automatic
> disabling
On 2/12/2021 4:56 PM, Vladimir Oltean wrote:
> On Fri, Feb 12, 2021 at 12:57:19PM -0800, Florian Fainelli wrote:
>> We have a number of unused flags defined today and since we are scarce
>> on space and may need to introduce new flags in the future remove and
>> shift every existing flag down
Hi Linus,
>> The machine is running a 'AMD Ryzen Threadripper 2950X 16-Core Processor'
>> and is freezing without any trace every view days.
>
> I don't think the first-gen Zen issues ever really got solved. There
> were multiple ones, with random segfaults for the early ones (but
> afaik those
Append raw to the direct variants of kvm_register_read/write(), and
drop the "l" from the mode-aware variants. I.e. make the mode-aware
variants the default, and make the direct variants scary sounding so as
to discourage use. Accessing the full 64-bit values irrespective of
mode is rarely the
On Thu, Feb 11, 2021 at 3:21 PM David Howells wrote:
>
> Most of the development discussion took place on IRC and waving snippets of
> code about in pastebin rather than email - the latency of email is just too
> high. There's not a great deal I can do about that now as I haven't kept IRC
>
On Fri, Feb 12, 2021 at 6:40 AM Alex Elder wrote:
>
> Introduce a new function to abstract the knowledge of whether hashed
> routing and filter tables are supported for a given IPA instance.
>
> IPA v4.2 is the only one that doesn't support hashed tables (now
> and for the foreseeable future),
Truncate RAX to 32 bits, i.e. consume EAX, when retrieving the hypecall
index for a Xen hypercall. Per Xen documentation[*], the index is EAX
when the vCPU is not in 64-bit mode.
[*]
http://xenbits.xenproject.org/docs/sphinx-unstable/guest-guide/x86/hypercall-abi.html
Fixes: 23200b7a30de
Drop bits 63:32 of RAX when grabbing the address for INVLPGA emulation
outside of 64-bit mode to make KVM's emulation slightly less wrong. The
address for INVLPGA is determined by the effective address size, i.e.
it's not hardcoded to 64/32 bits for a given mode. Add a FIXME to call
out that the
Drop bits 63:32 of the base and/or index GPRs when calculating the
effective address of a VMX instruction memory operand. Outside of 64-bit
mode, memory encodings are strictly limited to E*X and below.
Fixes: 064aea774768 ("KVM: nVMX: Decoding memory operands of VMX instructions")
Cc:
Drop bits 63:32 on loads/stores to/from DRs and CRs when the vCPU is not
in 64-bit mode. The APM states bits 63:32 are dropped for both DRs and
CRs:
In 64-bit mode, the operand size is fixed at 64 bits without the need
for a REX prefix. In non-64-bit mode, the operand size is fixed at 32
Drop bits 63:32 of the VMCS field encoding when checking for a nested
VM-Exit on VMREAD/VMWRITE in !64-bit mode. VMREAD and VMWRITE always
use 32-bit operands outside of 64-bit mode.
The actual emulation of VMREAD/VMWRITE does the right thing, this bug is
purely limited to incorrectly causing a
Drop bits 63:32 when storing a DR/CR to a GPR when the vCPU is not in
64-bit mode. Per the SDM:
The operand size for these instructions is always 32 bits in non-64-bit
modes, regardless of the operand-size attribute.
CR8 technically isn't affected as CR8 isn't accessible outside of 64-bit
Check CR3 for an invalid GPA even if the vCPU isn't in long mode. For
bigger emulation flows, notably RSM, the vCPU mode may not be accurate
if CR0/CR4 are loaded after CR3. For MOV CR3 and similar flows, the
caller is responsible for truncating the value.
Note, SMRAM.CR3 is read-only, so this
Remove the emulator's checks for illegal CR0, CR3, and CR4 values, as
the checks are redundant, outdated, and in the case of SEV's C-bit,
broken. The emulator manually calculates MAXPHYADDR from CPUID and
neglects to mask off the C-bit. For all other checks, kvm_set_cr*() are
a superset of the
Patches 01 and 02 fix theoretical bugs related to loading CRs through
the emulator. The rest of the patches are a bunch of small fixes for
cases where KVM reads/writes a 64-bit register outside of 64-bit mode.
I stumbled on this when puzzling over commit 0107973a80ad ("KVM: x86:
Introduce
On Fri, Feb 12, 2021 at 4:26 PM Stefan Metzmacher wrote:
>
> The machine is running a 'AMD Ryzen Threadripper 2950X 16-Core Processor'
> and is freezing without any trace every view days.
I don't think the first-gen Zen issues ever really got solved. There
were multiple ones, with random
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Fri, 12 Feb 2021 08:33:57 -0600 you wrote:
> Version 3 of this series uses dev_err_probe() in the second patch,
> as suggested by Heiner Kallweit.
>
> Version 2 was sent to ensure the series was based on current
>
On Fri, Feb 12, 2021 at 12:57:19PM -0800, Florian Fainelli wrote:
> We have a number of unused flags defined today and since we are scarce
> on space and may need to introduce new flags in the future remove and
> shift every existing flag down into a contiguous assignment. No
> functional change.
Am 12.02.21 um 21:39 schrieb Steve French:
> Metze/Bjorn,
> Linus is right - samba.org is down for me (I also verified with JRA).
> Any ETA on when it gets back up?
>
> On Fri, Feb 12, 2021 at 2:05 PM Linus Torvalds
> wrote:
>>
>> On Fri, Feb 12, 2021 at 10:16 AM Steve French wrote:
>>>
>>>
Quoting Taniya Das (2021-02-10 10:26:18)
> Add device tree bindings for global clock subsystem clock
> controller for Qualcomm Technology Inc's SC7280 SoCs.
>
> Signed-off-by: Taniya Das
> ---
Applied to clk-next
Quoting Taniya Das (2021-02-10 10:26:19)
> Add support for the global clock controller found on SC7280
> based devices. This should allow most non-multimedia device
> drivers to probe and control their clocks.
>
> Signed-off-by: Taniya Das
> ---
Applied to clk-next
On 2/9/21 11:12 PM, Miaohe Lin wrote:
> We should not transfer the per-node surplus state when we do not cross the
> node in order to save some cpu cycles
>
> Signed-off-by: Miaohe Lin
> ---
> mm/hugetlb.c | 6 ++
> 1 file changed, 6 insertions(+)
Thanks,
I was going to comment that the
From: Makarand Sonare
Currently, if enable_pml=1 PML remains enabled for the entire lifetime
of the VM irrespective of whether dirty logging is enable or disabled.
When dirty logging is disabled, all the pages of the VM are manually
marked dirty, so that PML is effectively non-operational.
Store the vendor-specific dirty log size in a variable, there's no need
to wrap it in a function since the value is constant after
hardware_setup() runs.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm-x86-ops.h | 1 -
arch/x86/include/asm/kvm_host.h| 2 +-
Add a sanity check in kvm_mmu_slot_apply_flags to assert that the
LOG_DIRTY_PAGES flag is indeed being toggled, and explicitly rely on
that holding true when zapping collapsible SPTEs. Manipulating the
CPU dirty log (PML) and write-protection also relies on this assertion,
but that's not obvious
Remove several exports from the MMU that are no longer necessary.
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/mmu/mmu.c | 35 ++---
2 files changed, 15 insertions(+), 21
Drop kvm_mmu_slot_largepage_remove_write_access() and refactor its sole
caller to use kvm_mmu_slot_remove_write_access(). Remove the now-unused
slot_handle_large_level() and slot_handle_all_level() helpers.
No functional change intended.
Signed-off-by: Sean Christopherson
---
Drop the facade of KVM's PML logic being vendor specific and move the
bits that aren't truly VMX specific into common x86 code. The MMU logic
for dealing with PML is tightly coupled to the feature and to VMX's
implementation, bouncing through kvm_x86_ops obfuscates the code without
providing any
Stop setting dirty bits for MMU pages when dirty logging is disabled for
a memslot, as PML is now completely disabled when there are no memslots
with dirty logging enabled.
This means that spurious PML entries will be created for memslots with
dirty logging disabled if at least one other memslot
Expand the comment about need to use write-protection for nested EPT
when PML is enabled to clarify that the tagging is a nop when PML is
_not_ enabled. Without the clarification, omitting the PML check looks
wrong at first^Wfifth glance.
Signed-off-by: Sean Christopherson
---
Unconditionally disable PML in vmcs02, KVM emulates PML purely in the
MMU, e.g. vmx_flush_pml_buffer() doesn't even try to copy the L2 GPAs
from vmcs02's buffer to vmcs12. At best, enabling PML is a nop. At
worst, it will cause vmx_flush_pml_buffer() to record bogus GFNs in the
dirty logs.
When zapping SPTEs in order to rebuild them as huge pages, use the new
helper that computes the max mapping level to detect whether or not a
SPTE should be zapped. Doing so avoids zapping SPTEs that can't
possibly be rebuilt as huge pages, e.g. due to hardware constraints,
memslot alignment,
Pass the memslot to the rmap callbacks, it will be used when zapping
collapsible SPTEs to verify the memslot is compatible with hugepages
before zapping its SPTEs.
No functional change intended.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 24 +++-
1 file
Factor out the logic for determining the maximum mapping level given a
memslot and a gpa. The helper will be used when zapping collapsible
SPTEs when disabling dirty logging, e.g. to avoid zapping SPTEs that
can't possibly be rebuilt as hugepages.
No functional change intended.
Signed-off-by:
Respect start_level when write-protect pages in the TDP MMU for dirty
logging. When the dirty bitmaps are initialized with all bits set, small
pages don't need to be write-protected as they've already been marked
dirty.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 2 +-
1
Zap SPTEs that are backed by ZONE_DEVICE pages when zappings SPTEs to
rebuild them as huge pages in the TDP MMU. ZONE_DEVICE huge pages are
managed differently than "regular" pages and are not compound pages.
Cc: Ben Gardon
Fixes: 14881998566d ("kvm: x86/mmu: Support disabling dirty logging for
Paolo, this is more or less ready, but on final read-through before
sending I realized it would be a good idea to WARN during VM destruction
if cpu_dirty_logging_count is non-zero. I wanted to get you this before
the 5.12 window opens in case you want the TDP MMU fixes for 5.12. I'll
do the
Quoting Taniya Das (2021-02-10 09:13:49)
> Add bindings and update documentation for clock rpmh driver on SC7280.
>
> Signed-off-by: Taniya Das
> ---
Applied to clk-next
Quoting Taniya Das (2021-02-10 09:13:50)
> Add support for RPMH clocks on SC7280 SoCs.
>
> Signed-off-by: Taniya Das
> ---
Applied to clk-next
Hi Alex,
I love your patch! Yet something to improve:
[auto build test ERROR on vfio/next]
[also build test ERROR on v5.11-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
On Wed, 10 Feb 2021 04:47:34 PST (-0800), sch...@linux-m68k.org wrote:
On Feb 04 2021, Palmer Dabbelt wrote:
From: Palmer Dabbelt
VSC8541 phys need a special reset sequence, which the driver doesn't
currentlny support. As a result enabling the reset via GPIO essentially
guarnteees that the
On Fri, Feb 12, 2021 at 04:37:09PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 12, 2021 at 03:48:51PM -0800, Paul E. McKenney wrote:
> > On Fri, Feb 12, 2021 at 10:12:07PM +0100, Uladzislau Rezki wrote:
> > > On Fri, Feb 12, 2021 at 08:20:59PM +0100, Sebastian Andrzej Siewior wrote:
> > > > On
On Fri, 2021-02-12 at 17:48 -0600, Eric W. Biederman wrote:
> Matthew Wilcox writes:
> > On Fri, Feb 12, 2021 at 04:01:48PM -0600, Eric W. Biederman wrote:
> > > Perhaps we can do something like:
> > >
> > > #define S_IRWX 7
> > > #define S_IRW_ 6
> > > #define S_IR_X 5
> > > #define S_IR__ 4
>
The intvec handler stores the caches ee in a local variable for use in
processing the intvec. When determining if a syserr is a fatal error or
not, the intvec handler is using the cached version, when it should be
using the current ee read from the device. Currently, the device could
be in the
On Fri, 2021-02-12 at 17:44 -0600, Eric W. Biederman wrote:
> I certainly do not see sufficient consensus to go around changing code
> other people maintain.
Every patch by a non-maintainer that doesn't have commit rights to
whatever tree is just a proposal.
> My suggest has the nice property
On Fri, Feb 12, 2021 at 03:48:51PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 12, 2021 at 10:12:07PM +0100, Uladzislau Rezki wrote:
> > On Fri, Feb 12, 2021 at 08:20:59PM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2020-12-09 21:27:32 [+0100], Uladzislau Rezki (Sony) wrote:
> > > > Add self
Quoting Greg KH (2021-02-11 05:00:51)
> On Wed, Feb 10, 2021 at 01:44:35PM +0200, Tudor Ambarus wrote:
> > This is a follow-up for:
> > commit 3c9ea42802a1 ("clk: Mark fwnodes when their clock provider is
> > added/removed")
> >
> > The above commit updated the deprecated of_clk_add_provider(),
From: Ignacio Alvarado
This test launches 512 VMs in serial and kills them after a random
amount of time.
The test was original written to exercise KVM user notifiers in
the context of1650b4ebc99d:
- KVM: Disable irq while unregistering user notifier
-
Quoting Lee Jones (2021-02-12 14:37:39)
> On Fri, 12 Feb 2021, Stephen Boyd wrote:
>
> >
> > I'd like to enable it for only files under drivers/clk/ but it doesn't
> > seem to work. I'm not asking to enable it at the toplevel Makefile. I'm
> > asking to enable it for drivers/clk/ so nobody has
The FT260 is a USB device that implements USB to I2C/UART bridges
through two USB HID class interfaces. The first - for I2C, and the
second for UART. Each interface is independent, and the kernel
detects it as a separate hidraw device.
This commit adds I2C host adapter support, enabling a wide
The FT260 is a USB device that implements USB to I2C/UART bridges
through two USB HID class interfaces. The first - for I2C, and the
second for UART. Each interface is independently controlled, and
the kernel detects each interface as a separate hidraw device.
This commit adds I2C host adapter
On Fri, Feb 12, 2021 at 12:06:00PM +0100, Lukasz Majczak wrote:
> There are missing calls to tpm_request_locality() before the calls to
> the tpm_get_timeouts() and tpm_tis_probe_irq_single() - both functions
> internally send commands to the tpm using tpm_tis_send_data()
> which in turn, at the
On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote:
> On Fri, Feb 12, 2021 at 03:07:39PM -0800, Ian Lance Taylor wrote:
> > On Fri, Feb 12, 2021 at 3:03 PM Dave Chinner wrote:
> > >
> > > On Fri, Feb 12, 2021 at 04:45:41PM +0100, Greg KH wrote:
> > > > On Fri, Feb 12, 2021 at 07:33:57AM
Philipp, Fabio,
I was able to verify that the PREs do indeed overrun their allocated ocram area.
Section 38.5.1 of the iMX6QuadPlus manual indicates the ocram size
required: width(pixels) x 8 lines x 4 bytes. For 2048 pixels max, this
comes to 64K. This is what the PRE driver allocates. So far,
On Thu, Feb 11, 2021 at 05:16:56PM +, Ken Moffat wrote:
> Hi,
>
> in 5.10 kernels up to and including 5.10.15 when trying to build the
> kernel for an x86_64 skylake using binutils-2.36.1, gcc-10.2 and
> glibic-2.33 I get a segfault in objtool if the orc unwinder is
> enabled.
>
> This has
On Fri, Feb 12, 2021 at 10:12:07PM +0100, Uladzislau Rezki wrote:
> On Fri, Feb 12, 2021 at 08:20:59PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2020-12-09 21:27:32 [+0100], Uladzislau Rezki (Sony) wrote:
> > > Add self tests for checking of RCU-tasks API functionality.
> > > It covers:
> > >
Matthew Wilcox writes:
> On Fri, Feb 12, 2021 at 04:01:48PM -0600, Eric W. Biederman wrote:
>> Joe Perches writes:
>>
>> > Convert S_ permissions to the more readable octal.
>> >
>> > Done using:
>> > $ ./scripts/checkpatch.pl -f --fix-inplace --types=SYMBOLIC_PERMS
>> > fs/proc/*.[ch]
>> >
On Thu, Feb 11, 2021 at 02:54:35PM -0500, Nayna Jain wrote:
> The kernel currently only loads the kernel module signing key onto
> the builtin trusted keyring. To support IMA, load the module signing
> key selectively either onto builtin or ima keyring based on MODULE_SIG
> -Original Message-
> From: Arnd Bergmann [mailto:a...@kernel.org]
> Sent: Saturday, February 13, 2021 12:06 PM
> To: Song Bao Hua (Barry Song)
> Cc: t...@linutronix.de; gre...@linuxfoundation.org; a...@arndb.de;
> ge...@linux-m68k.org; fun...@jurai.org; ph...@gnu.org; cor...@lwn.net;
1 - 100 of 1096 matches
Mail list logo
