From: Min Li
Add deprecated flag to indicate < v4.8.7.
Fix idtcm_enable_tod() call correct settime().
Signed-off-by: Min Li
---
drivers/ptp/ptp_clockmatrix.c | 69 ---
drivers/ptp/ptp_clockmatrix.h | 11 +++
2 files changed, 45 insertions(+), 35
On Thu, Dec 03, 2020 at 10:46:29AM +0200, Joonas Lahtinen wrote:
> Quoting Bjorn Helgaas (2020-12-02 22:22:53)
> > On Wed, Dec 02, 2020 at 05:21:58AM +, Surendrakumar Upadhyay,
> > TejaskumarX wrote:
> > > Yes it fails all the tests which are allocating from this stolen
> > > memory bunch.
From: Min Li
SM_RESET device only when loading full configuration and check
for BOOT_STATUS. Also remove polling for write trigger done in
_idtcm_settime().
Signed-off-by: Min Li
---
drivers/ptp/idt8a340_reg.h| 1 +
drivers/ptp/ptp_clockmatrix.c | 152
Hi,
On Thu, Dec 3, 2020 at 3:33 AM Rakesh Pillai wrote:
>
> > What I'm trying to say is this. Imagine that:
> >
> > a) the device tree has the "variant" property.
> >
> > b) the BRD file has two entries, one for "board-id" (1) and one for
> > "board-id + chip-id" (2). It doesn't have one for
Hello,
On Thu, Dec 03, 2020 at 06:28:41PM +0800, Hillf Danton wrote:
> + new_cpu = cpumask_any_and_distribute(wq_unbound_cpumask,
> cpu_online_mask);
> + if (new_cpu < nr_cpu_ids)
> + return new_cpu;
> + else
> + return cpu;
> }
>
> static void
On 03.12.20 15:04, Theodore Y. Ts'o wrote:
On Thu, Oct 15, 2020 at 03:26:28PM +0200, Alexander Lochmann wrote:
Hi folks,
I've updated the lock documentation according to our finding for
transaction_t.
Does this patch look good to you?
I updated the annotations to match with the local
On Thursday, 3 December 2020, 15:12:55 CET, Richard Cochran wrote:
> On Thu, Dec 03, 2020 at 11:21:17AM +0100, Christian Eggers wrote:
> > The KSZ9563 has a Trigger Output Unit (TOU) which can be used to
> > generate periodic signals.
> >
> > The pulse length can be altered via a device
On 12/3/20 1:09 PM, Daniel Lezcano wrote:
On 18/11/2020 13:03, Lukasz Luba wrote:
Devfreq cooling needs to now the correct status of the device in order
to operate. Do not rely on Devfreq last_status which might be a stale data
and get more up-to-date values of the load.
Devfreq framework
On Thu, Dec 03, 2020 at 12:08:50PM +, Brendan Jackman wrote:
> This object lives inside the trunner output dir,
> i.e. tools/testing/selftests/bpf/no_alu32/btf_data.o
>
> At some point it gets copied into the parent directory during another
> part of the build, but that doesn't happen when
Alexandre,
On Thu, Dec 03 2020 at 03:10, Alexandre Belloni wrote:
> On 03/12/2020 02:14:12+0100, Thomas Gleixner wrote:
>> That said, can somebody answer the one million dollar question which
>> problem is solved by all of this magic nonsense?
>>
> The goal was to remove the 500ms offset for all
On Thu, Nov 26, 2020 at 04:13:16PM +0200, James Clark wrote:
> Changes since v5:
> * Fix test for cpu_map__get_die() by shifting id before testing.
> * Fix test for cpu_map__get_socket() by not using cpu_map__id_to_socket()
> which is only valid in CPU aggregation mode.
>
> James Clark
On Thu, Dec 03, 2020 at 11:20:02AM +, Stefan Hajnoczi wrote:
> On Wed, Dec 02, 2020 at 10:45:11AM -0500, Peter Xu wrote:
> > On Wed, Dec 02, 2020 at 02:33:56PM +, Stefan Hajnoczi wrote:
> > > On Wed, Nov 25, 2020 at 10:57:11AM -0500, Peter Xu wrote:
> > > > On Wed, Nov 25, 2020 at
On 18/11/2020 13:03, Lukasz Luba wrote:
> The Energy Model (EM) framework supports devices such as Devfreq. Create
> new registration functions which automatically register EM for the thermal
> devfreq_cooling devices. This patch prepares the code for coming changes
> which are going to replace
From: Bongsu Jeon
If there isn't proper NFC firmware image,
Bootloader mode will be skipped.
Signed-off-by: Bongsu Jeon
---
drivers/nfc/s3fwrn5/core.c | 44 --
drivers/nfc/s3fwrn5/firmware.c | 11 +
drivers/nfc/s3fwrn5/firmware.h | 1 +
3 files
On 03/12/2020 15:02, Chen-Yu Tsai wrote:
> On Thu, Dec 3, 2020 at 6:54 PM André Przywara wrote:
>>
>> On 03/12/2020 03:16, Samuel Holland wrote:
>>
>> Hi,
>>
>>> On 12/2/20 7:54 AM, Andre Przywara wrote:
>>> ...
+soc {
+compatible = "simple-bus";
+
From: Eric Dumazet
Date: Thu, 3 Dec 2020 15:31:53 +0100
> On Thu, Dec 3, 2020 at 3:14 PM Kuniyuki Iwashima wrote:
> >
> > From: Eric Dumazet
> > Date: Tue, 1 Dec 2020 16:25:51 +0100
> > > On 12/1/20 3:44 PM, Kuniyuki Iwashima wrote:
> > > > This patch lets reuseport_detach_sock() return
On Thu, 3 Dec 2020 19:26:35 +0800, Zou Wei wrote:
> Fix the following sparse warnings:
>
> drivers/regulator/da9121-regulator.c:55:21: warning: symbol
> 'da9121_10A_2phase_current' was not declared. Should it be static?
> drivers/regulator/da9121-regulator.c:63:21: warning: symbol
>
0
>
> fix mm-truncateshmem-handle-truncates-that-split-thps.patch
This patch landed in todays linux-next (20201203) as commit 8678b27f4b8b
("8678b27f4b8bfc130a13eb9e9f27171bcd8c0b3b"). Sadly it breaks booting of
ANY of my ARM 32bit test systems, which use initrd. ARM64bit based
On Wed, Dec 2, 2020 at 10:31 PM Mike Rapoport wrote:
>
> From: Mike Rapoport
>
> Account memory consumed by secretmem to memcg. The accounting is updated
> when the memory is actually allocated and freed.
>
> Signed-off-by: Mike Rapoport
> Acked-by: Roman Gushchin
Reviewed-by: Shakeel Butt
> -Original Message-
> From: Patrick Havelange
> Sent: 03 December 2020 15:51
> To: Madalin Bucur ; David S. Miller
> ; Jakub Kicinski ;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: Patrick Havelange
> Subject: [PATCH net 1/4] net: freescale/fman: Split the main resource
On Thu, Dec 03, 2020 at 08:34:32PM +0800, Charles wrote:
[ ... ]
>
> It's really weird. I sent a mail to myself, and it looks good.
> @@ -220,6 +220,15 @@ config SENSORS_MP2975
> This driver can also be built as a module. If so, the module will
> be called mp2975.
> +config
On 12/3/20 3:43 AM, Muchun Song wrote:
> On Thu, Dec 3, 2020 at 8:03 AM Vlastimil Babka wrote:
>>
>> On 12/2/20 1:21 PM, Muchun Song wrote:
>> > The max order page has no buddy page and never merge to other order.
>> > So isolating and then freeing it is pointless.
>> >
>> > Signed-off-by: Muchun
> -Original Message-
> From: Anders Roxell
> Sent: 03 December 2020 16:44
> To: Madalin Bucur ; da...@davemloft.net;
> k...@kernel.org; a...@kernel.org; dan...@iogearbox.net; h...@kernel.org;
> john.fastab...@gmail.com
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
On Thu, Dec 03, 2020 at 03:10:47AM +0100, Alexandre Belloni wrote:
> IIRC, used in conjunction with rtc_hctosys which also adds
> inconditionnaly 500ms this can ends up with the system time
> being one second away from the wall clock time which NTP will take quite
> some time to remove.
I can't
On 03/12/20 13:03, Peter Zijlstra wrote:
> On Thu, Nov 26, 2020 at 06:18:33PM +, Valentin Schneider wrote:
>> If I got the RCU bits right from what Thomas mentioned in
>>
>> https://lore.kernel.org/r/87ft5q18qs@nanos.tec.linutronix.de
>>
On Thu, 3 Dec 2020 at 17:36, Christian Eggers wrote:
> Should ptp_sysfs be extended with a "pulse" attribute with calls
> enable() with only PTP_PEROUT_DUTY_CYCLE set?
Use tools/testing/selftests/ptp/testptp.
This patch adds the driver data for two rt1011 speaker amplifiers on
SSP1 and rt5682 on SSP0 for TGL platform. DAI format for rt1011 is
leveraged from cml_rt1011_rt5682 which is 4-slot tdm with 100fs bclk.
Signed-off-by: Brent Lu
---
sound/soc/intel/boards/Kconfig| 1 +
On Thu, Dec 03, 2020 at 04:07:42PM +0100, Greg KH wrote:
> On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote:
> > PS: Greg I know I promised some review on newcomer patches to help with
> > your queue, unfortunately Intel-internal review is keeping my plate
> > full. Again, I do not
> I like the cleanup so far, even at this point it's a relief to finally
> see the nested ifdefs get removed.
>
> One naming nit/idea below, but this looks fine as is, so:
>
> Reviewed-by: John Hubbard
Thank you for reviewing this series.
> Maybe naming it "movable_page_list", would be a nice
On Thu, 3 Dec 2020 10:43:22 -0500
Peter Xu wrote:
> On Thu, Dec 03, 2020 at 11:20:02AM +, Stefan Hajnoczi wrote:
> > On Wed, Dec 02, 2020 at 10:45:11AM -0500, Peter Xu wrote:
> > > On Wed, Dec 02, 2020 at 02:33:56PM +, Stefan Hajnoczi wrote:
> > > > On Wed, Nov 25, 2020 at 10:57:11AM
On 12/3/2020 7:12 AM, Dave Hansen wrote:
On 12/3/20 1:19 AM, Borislav Petkov wrote:
On Tue, Nov 10, 2020 at 08:21:51AM -0800, Yu-cheng Yu wrote:
Before introducing _PAGE_COW for non-hardware memory management purposes in
the next patch, rename _PAGE_DIRTY to _PAGE_DIRTY_HW and _PAGE_BIT_DIRTY
On Tue 2020-12-01 21:59:39, John Ogness wrote:
> In preparation for removing logbuf_lock, inline log_output()
> and log_store() into vprintk_store(). This will simplify dealing
> with the various code branches and fallbacks that are possible.
> ---
> kernel/printk/printk.c | 134
> > +struct {
> > + unsigned int tx;
> > + unsigned int rx;
> > +} rt1011_tdm_mask[] = {
> > + {.tx = 0x4, .rx = 0x1},
> > + {.tx = 0x8, .rx = 0x2},
> > +};
>
> as noted in the GitHub review this should be static and possibly const.
Will fix in v2. Also add const to structures in
On 12/3/20 8:05 AM, Catalin Marinas wrote:
> On Thu, Dec 03, 2020 at 07:36:10AM -0700, Jens Axboe wrote:
>> On 12/3/20 4:01 AM, Catalin Marinas wrote:
>>> On Thu, Dec 03, 2020 at 02:25:30PM +1100, Stephen Rothwell wrote:
diff --cc arch/arm64/include/asm/thread_info.h
index
On Thu, Dec 03, 2020 at 01:30:30PM +, hsu.yungt...@outlook.com wrote:
> Add the pmbus driver for the STMicroelectronics pm6764 voltage regulator.
>
> the output voltage use the MFR_READ_VOUT 0xD4
> vout value returned is linear11
>
checkpatch --strict reports:
total: 3 errors, 7 warnings,
On Mon, Nov 30, 2020 at 12:40AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:6147c83f Add linux-next specific files for 20201126
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=117c967950
> kernel config:
On Thu, 3 Dec 2020, Vitaly Wool wrote:
> Introduce XIP (eXecute In Place) support for RISC-V platforms.
> It allows code to be executed directly from non-volatile storage
> directly addressable by the CPU, such as QSPI NOR flash which can
> be found on many RISC-V platforms. This makes way for
Reviewed-by: Steve Wahl
On Thu, Dec 03, 2020 at 09:22:52AM -0600, Mike Travis wrote:
> Fix UV4 Hub Revision adjustment as Hub chip starts with revision 1.
> Incorrectly identifies UV4 as UV4A and UV4A as UV5.
>
> Fixes 647128f1536ef: x86/platform/uv: Update UV MMRs for UV5
>
> Signed-off-by:
Gentle ping, haven't seen any response...
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com
Please consider the
On 12/2/2020 10:00 PM, Jordan Crouse wrote:
On Wed, Dec 02, 2020 at 08:53:51PM +0530, Akhil P Oommen wrote:
On 11/30/2020 10:32 PM, Jordan Crouse wrote:
On Fri, Nov 27, 2020 at 06:19:44PM +0530, Akhil P Oommen wrote:
So far a530v2 gpu has support for detecting its supported opps
based on a
On 03.12.20 16:43, Peter Xu wrote:
> On Thu, Dec 03, 2020 at 11:20:02AM +, Stefan Hajnoczi wrote:
>> On Wed, Dec 02, 2020 at 10:45:11AM -0500, Peter Xu wrote:
>>> On Wed, Dec 02, 2020 at 02:33:56PM +, Stefan Hajnoczi wrote:
On Wed, Nov 25, 2020 at 10:57:11AM -0500, Peter Xu wrote:
Status of the patches
=
Thanks for the reviews! Differences from v2->v3 [1]:
* More minor fixes and naming/comment changes
* Dropped atomic subtract: compilers can implement this by preceding
an atomic add with a NEG instruction (which is what the x86 JIT did
under the
The JIT case for encoding atomic ops is about to get more
complicated. In order to make the review & resulting code easier,
let's factor out some shared helpers.
Signed-off-by: Brendan Jackman
Change-Id: I66dbd5ad0bf6f820901fb73d6b2c6a63e00483b1
---
arch/x86/net/bpf_jit_comp.c | 39
The case for JITing atomics is about to get more complicated. Let's
factor out some common code to make the review and result more
readable.
NB the atomics code doesn't yet use the new helper - a subsequent
patch will add its use as a side-effect of other changes.
Signed-off-by: Brendan Jackman
This value can be set in bpf_insn.imm, for BPF_ATOMIC instructions,
in order to have the previous value of the atomically-modified memory
location loaded into the src register after an atomic op is carried
out.
Suggested-by: Yonghong Song
Signed-off-by: Brendan Jackman
Change-Id:
A later commit will need to lookup a subset of these opcodes. To
avoid duplicating code, pull out a table.
The shift opcodes won't be needed by that later commit, but they're
already duplicated, so fold them into the table anyway.
Change-Id: Ia6888f9fa65da6225c33b530ea16911bf2f70750
This adds two atomic opcodes, both of which include the BPF_FETCH
flag. XCHG without the BPF_FETCh flag would naturally encode
atomic_set. This is not supported because it would be of limited
value to userspace (it doesn't imply any barriers). CMPXCHG without
BPF_FETCH woulud be an atomic
I can't find a reason why this code is in resolve_pseudo_ldimm64;
since I'll be modifying it in a subsequent commit, tidy it up.
Change-Id: I3410469270f4889a3af67612bd6c2e7979ab4da1
Signed-off-by: Brendan Jackman
---
kernel/bpf/verifier.c | 13 ++---
1 file changed, 6 insertions(+), 7
There's currently only one usage of this but implementation of
atomic_sub add another.
Change-Id: Ia56743ec26ff5e7bcde8ae94fa17fef92d418d2b
Signed-off-by: Brendan Jackman
---
arch/x86/net/bpf_jit_comp.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git
Since the atomic operations that are added in subsequent commits are
all isomorphic with BPF_ADD, pull out a macro to avoid the
interpreter becoming dominated by lines of atomic-related code.
Note that this sacrificies interpreter performance (combining
STX_ATOMIC_W and STX_ATOMIC_DW into single
This relies on the work done by Yonghong Song in
https://reviews.llvm.org/D72184
Note the use of a define called ENABLE_ATOMICS_TESTS: this is used
to:
- Avoid breaking the build for people on old versions of Clang
- Avoid needing separate lists of test objects for no_alu32, where
atomics
A subsequent patch will add additional atomic operations. These new
operations will use the same opcode field as the existing XADD, with
the immediate discriminating different operations.
In preparation, rename the instruction mode BPF_ATOMIC and start
calling the zero immediate BPF_ADD.
This is
This adds instructions for
atomic[64]_[fetch_]and
atomic[64]_[fetch_]or
atomic[64]_[fetch_]xor
All these operations are isomorphic enough to implement with the same
verifier, interpreter, and x86 JIT code, hence being a single commit.
The main interesting thing here is that x86 doesn't directly
Change-Id: Ic70fe9e3cb4403df4eb3be2ea5ae5af53156559e
Signed-off-by: Brendan Jackman
---
Documentation/networking/filter.rst | 26 ++
1 file changed, 26 insertions(+)
diff --git a/Documentation/networking/filter.rst
b/Documentation/networking/filter.rst
index
Change-Id: Ia15bb76f7152fff2974e38242d7430ce2987a71e
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Quentin Monnet
Cc: "Frank Ch. Eigler"
Cc: Stephane Eranian
Cc: Namhyung Kim
Cc: Thomas Hebb
Change-Id: Ie2c3832eaf050d627764071d1927c7546e7c4b4b
Signed-off-by: Brendan Jackman
---
This is somewhat cargo-culted from the libbpf build. It will be used
in a subsequent patch to query for Clang BPF atomics support.
Change-Id: I9318a1702170eb752acced35acbb33f45126c44c
Signed-off-by: Brendan Jackman
---
tools/testing/selftests/bpf/.gitignore | 1 +
Srinivasan Raju writes:
> we will be submitting to linux-firmware repository @
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
> I will share the link once it is accpeted, we have sent another
> version of the patch v8 , please review and provide your comments
What
de
[5.158585][T0] #PF: error_code(0x) - not-present page
[5.164438][T0] PGD 0 P4D 0
[5.167670][T0] Oops: [#1] SMP KASAN NOPTI
[5.172566][T0] CPU: 0 PID: 0 Comm: swapper Not tainted
5.10.0-rc6-next-20201203+ #3
[5.180685][T0] Hardware name: HPE ProL
From: ChiYuan Huang
This adds support Richtek RT4831 MFD core. It includes four channel WLED driver
and Display Bias Voltage outputs.
Signed-off-by: ChiYuan Huang
---
Changes since v2
- Add copyright.
- Refine error log text in probe.
- Refine comment lines in remove and shutdown callback.
-
From: ChiYuan Huang
Adds DT binding document for Richtek RT4831 backlight.
Signed-off-by: ChiYuan Huang
---
.../leds/backlight/richtek,rt4831-backlight.yaml | 86 ++
1 file changed, 86 insertions(+)
create mode 100644
From: ChiYuan Huang
Adds DT binding document for Richtek RT4831 DSV regulator.
Signed-off-by: ChiYuan Huang
---
.../regulator/richtek,rt4831-regulator.yaml| 67 ++
1 file changed, 67 insertions(+)
create mode 100644
From: ChiYuan Huang
Adds DT binding document for Richtek RT4831 MFD core.
This patch depends on
"backlight: rt4831: Adds DT binding document for Richtek RT4831 backlight".
"regulator: rt4831: Adds DT binding document for Richtek RT4831 DSV regulator".
Signed-off-by: ChiYuan Huang
---
Changes
On 03/12/2020 11:52:49-0400, Jason Gunthorpe wrote:
> On Thu, Dec 03, 2020 at 03:10:47AM +0100, Alexandre Belloni wrote:
>
> > IIRC, used in conjunction with rtc_hctosys which also adds
> > inconditionnaly 500ms this can ends up with the system time
> > being one second away from the wall clock
On 03/12/2020 16:38, Lukasz Luba wrote:
>
>
> On 12/3/20 1:09 PM, Daniel Lezcano wrote:
>> On 18/11/2020 13:03, Lukasz Luba wrote:
>>> Devfreq cooling needs to now the correct status of the device in order
>>> to operate. Do not rely on Devfreq last_status which might be a stale
>>> data
>>> and
Okay then I will wait for someone to respond with "Reviewed-by". So this can be
merged.
Thanks,
Tejas
> -Original Message-
> From: Bjorn Helgaas
> Sent: 03 December 2020 20:55
> To: Joonas Lahtinen
> Cc: Surendrakumar Upadhyay, TejaskumarX
> ; Jesse Barnes
> ; Daniel Vetter ; Linux
On Fri, Nov 27, 2020 at 03:21:11PM +, Steven Price wrote:
> It's been a week, and I think the comments on v5 made it clear that
> enforcing PROT_MTE requirements on the VMM was probably the wrong
> approach. So since I've got swap working correctly without that I
> thought I'd post a v6 which
On Thu, Dec 03, 2020 at 04:02:31PM +, Brendan Jackman wrote:
[...]
> [1] Previous patchset:
> https://lore.kernel.org/bpf/20201123173202.1335708-1-jackm...@google.com/
Sorry, bogus link. That's v1, here's v2:
https://lore.kernel.org/bpf/20201127175738.1085417-1-jackm...@google.com/
Hi!
On 2020-12-03 15:42, Chuhong Yuan wrote:
> setcmap_legacy() does not call drm_modeset_unlock_all() in some exits,
> add the missed unlocks with goto to fix it.
>
> Fixes: 964c60063bff ("drm/fb-helper: separate the fb_setcmap helper into
> atomic and legacy paths")
> Signed-off-by: Chuhong
On 02.12.20 17:12, Vitaly Kuznetsov wrote:
> Unlike virtio_balloon/virtio_mem/xen balloon drivers, Hyper-V balloon driver
> does not adjust managed pages count when ballooning/un-ballooning and this
> leads
> to incorrect stats being reported, e.g. unexpected 'free' output.
>
> Note, the
On Thu, Dec 03, 2020 at 09:48:57AM +0100, Borislav Petkov wrote:
> On Wed, Dec 02, 2020 at 05:32:32PM -0500, Arvind Sankar wrote:
> > The pfn_range_is_mapped() call just checks whether it is mapped at all
> > in the direct mapping. Is the TSEG range supposed to be marked as
> > non-RAM in the E820
On 02.12.20 17:12, Vitaly Kuznetsov wrote:
> 'alloc_unit' in alloc_balloon_pages() is either '512' for 2M allocations or
> '1' for 4k allocations. So
>
> 1 << get_order(alloc_unit << PAGE_SHIFT)
>
> equals to 'alloc_unit' and the for loop basically sets all them offline.
> Simplify the math to
PGD 0 P4D 0
> [5.167670][T0] Oops: [#1] SMP KASAN NOPTI
> [5.172566][T0] CPU: 0 PID: 0 Comm: swapper Not tainted
> 5.10.0-rc6-next-20201203+ #3
> [5.180685][T0] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
> Gen10, BIOS A40 07/10/2019
> [5.1
On Thu, Dec 03, 2020 at 04:39:21PM +0100, Thomas Gleixner wrote:
> The logic in sync_cmos_clock() and rtc_set_ntp_time() is different as I
> pointed out: sync_cmos_clock() hands -500ms to rtc_tv_nsec_ok() and
> rtc_set_ntp_time() uses +500ms, IOW exactly ONE second difference in
> behaviour.
I
On Fri, Dec 04, 2020 at 12:39:50AM +0900, Bongsu Jeon wrote:
> From: Bongsu Jeon
>
> If there isn't proper NFC firmware image,
> Bootloader mode will be skipped.
Wrap your commit msg as described in submitting patches (so at 75
character).
>
> Signed-off-by: Bongsu Jeon
> ---
>
On Thursday, 3 December 2020, 16:52:46 CET, Vladimir Oltean wrote:
> On Thu, 3 Dec 2020 at 17:36, Christian Eggers wrote:
> > Should ptp_sysfs be extended with a "pulse" attribute with calls
> > enable() with only PTP_PEROUT_DUTY_CYCLE set?
>
> Use tools/testing/selftests/ptp/testptp.
Thanks
On Thu, Dec 3, 2020 at 11:45 PM André Przywara wrote:
>
> On 03/12/2020 15:02, Chen-Yu Tsai wrote:
> > On Thu, Dec 3, 2020 at 6:54 PM André Przywara
> > wrote:
> >>
> >> On 03/12/2020 03:16, Samuel Holland wrote:
> >>
> >> Hi,
> >>
> >>> On 12/2/20 7:54 AM, Andre Przywara wrote:
> >>> ...
>
On 03/12/2020 16:18, Andrew Lunn wrote:
We don't want to enable HW based switch support unless explicitly
asked by user.
This is the key point. Why? Does individual ports when passed through
the switch not work properly? Does it add extra latency/jitter?
When switch mode is enabled the
The max order page has no buddy page and never merge to other order.
So isolating and then freeing it is pointless. And if order == MAX_ORDER
- 1, then the buddy can actually be a !pfn_valid() in some corner case?
pfn_valid_within(buddy_pfn) that follows would only catch it on archs
with holes in
On 2020-12-03, Petr Mladek wrote:
>> +if (lflags & LOG_CONT) {
>> +prb_rec_init_wr(, text_len);
>> +if (prb_reserve_in_last(, prb, , caller_id, LOG_LINE_MAX)) {
>> +memcpy(_buf[r.info->text_len], text, text_len);
>> +
On Thu, 3 Dec 2020, Geert Uytterhoeven wrote:
> DTB stores all values as 32-bit big-endian integers.
> Add a macro to convert such values to native CPU endianness, to reduce
> duplication.
>
> Signed-off-by: Geert Uytterhoeven
I agree with Ard's suggestions. In any case:
Reviewed-by: Nicolas
Hello.
On Thu, 3 Dec 2020, Chen-Yu Tsai wrote:
Hi,
On Mon, Nov 16, 2020 at 8:57 PM Martin Cerveny wrote:
Allwinner V3s has system control and SRAM C1 region similar to H3.
Signed-off-by: Martin Cerveny
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 14 ++
1 file changed, 14
On Thu, 3 Dec 2020, Geert Uytterhoeven wrote:
> The DTB magic marker is stored as a 32-bit big-endian value, and thus
> depends on the CPU's endianness. Add a macro to define this value in
> native endianness, to reduce #ifdef clutter and (future) duplication.
>
> Signed-off-by: Geert
On 03.12.20 01:03, Vlastimil Babka wrote:
> On 12/2/20 1:21 PM, Muchun Song wrote:
>> The max order page has no buddy page and never merge to other order.
>> So isolating and then freeing it is pointless.
>>
>> Signed-off-by: Muchun Song
>
> Acked-by: Vlastimil Babka
>
>> ---
>>
On Thu, Dec 3, 2020 at 4:58 PM Marco Elver wrote:
>
> On Mon, Nov 30, 2020 at 12:40AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:6147c83f Add linux-next specific files for 20201126
> > git tree: linux-next
> > console output:
On 02.12.20 13:21, Muchun Song wrote:
> The max order page has no buddy page and never merge to other order.
> So isolating and then freeing it is pointless.
>
> Signed-off-by: Muchun Song
> ---
> mm/page_isolation.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 03.12.20 17:22, Muchun Song wrote:
> The max order page has no buddy page and never merge to other order.
> So isolating and then freeing it is pointless. And if order == MAX_ORDER
> - 1, then the buddy can actually be a !pfn_valid() in some corner case?
> pfn_valid_within(buddy_pfn) that
I bundled this as a series, because otherwise there will be conflicts
because the "remove global protection flag" patches modify the same lines
as the main patch.
There are now two more patches:
mtd: spi-nor: sst: fix BPn bits for the SST25VF064C
mtd: spi-nor: ignore errors in
This flash part actually has 4 block protection bits.
Please note, that this patch is just based on information of the
datasheet of the datasheet and wasn't tested.
Reported-by: Tudor Ambarus
Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write
protection")
Signed-off-by:
Just try to unlock the whole SPI-NOR flash array. Don't abort the
probing in case of an error. Justifications:
(1) For some boards, this just works because
spi_nor_write_16bit_sr_and_check() is broken and just checks the
second half of the 16bit. Once that will be fixed, SPI probe will
These flashes have some weird BP bits mapping which aren't supported in
the current locking code. Just add a simple unlock op to unprotect the
entire flash array which is needed for legacy behavior.
Fixes: 3e0930f109e7 ("mtd: spi-nor: Rework the disabling of block write
protection")
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
Traditionally, linux unlocks the whole flash because there are legacy
devices which has the write protections bits set by default at startup.
If you actually want to use the flash protection bits, eg. because there
is a read-only part for a bootloader, this automatic unlocking is
harmful. If there
On Thu, 3 Dec 2020 at 09:37, Rui Salvaterra wrote:
>
> Thanks for the heads-up, I think I know where the problem is.
Then again, maybe not. I don't have a PowerPC machine to test, at the
moment, and all my x86(-64) machines work fine. If no one beats me to
it, I can debug on an iBook G4, but
For the Atmel and SST parts this flag was already moved to individual
flash parts because it is considered bad esp. because newer flash chips
will automatically inherit the "has locking" support. While this won't
likely be the case for the Intel parts, we do it for consistency
reasons.
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
-off-by: Yogesh Lal
>>> Signed-off-by: Vijayanand Jitta
>>
>> Reverting this commit on today's linux-next fixed boot crash with KASAN.
>>
>> .config:
>> https://cailca.coding.net/public/linux/mm/git/files/master/x86.config
>> https://cailca.cod
On Sat, Nov 14, 2020 at 2:01 AM Daniel Kiper wrote:
...
> The log specification should be as much as possible platform agnostic
> and self contained. The final version of this spec should be merged into
> existing specifications, e.g. UEFI, ACPI, Multiboot2, or be a standalone
> spec, e.g. as a
On Thu, 3 Dec 2020, Geert Uytterhoeven wrote:
> Currently, the start address of physical memory is obtained by masking
> the program counter with a fixed mask of 0xf800. This mask value
> was chosen as a balance between the requirements of different platforms.
> However, this does require
On Thu, 3 Dec 2020 at 17:27, Eric Dumazet wrote:
> On Thu, Dec 3, 2020 at 4:58 PM Marco Elver wrote:
> >
> > On Mon, Nov 30, 2020 at 12:40AM -0800, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:6147c83f Add linux-next specific files for
On Thu, 3 Dec 2020 09:50:11 +0100 Oleksij Rempel wrote:
> @Jakub,
>
> > You can't take sleeping locks from .ndo_get_stats64.
> >
> > Also regmap may sleep?
> >
> > + ret = regmap_read(priv->regmap, reg, );
>
> Yes. And underling layer is mdio bus which is by default sleeping as
> well.
>
1001 - 1100 of 1597 matches
Mail list logo
