A System Error (SError, followed by kernel panic) was detected when
trying to print the supported pins in a pinctrl device which supports
multiple pins per register. This change fixes the pcs_pin_dbg_show() in
pinctrl-single driver when bits_per_mux is not zero. In addition move
offset calculation
Remove unused parameter 'pin_pos' from pcs_add_pin().
Signed-off-by: Hanna Hawa
---
drivers/pinctrl/pinctrl-single.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 91c638b85d2c..f3394517cb2e
Remove unused parameter 'num_pins_in_register' from
pcs_allocate_pin_table().
Reported-by: kernel test robot
Signed-off-by: Hanna Hawa
---
drivers/pinctrl/pinctrl-single.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
These patches fix the pcs_pin_dbg_show() function for the scenario where
a single register controls multiple pins (i.e. bits_per_mux is not zero)
Additionally, the common formula is moved to a separate function to
allow reuse.
Changes since v3:
-
- define and set variable
On Thu, Mar 18, 2021 at 10:15:43PM +0100, Arnd Bergmann wrote:
> On Thu, Mar 18, 2021 at 5:13 PM Alessio Balsini wrote:
> > On Tue, Mar 16, 2021 at 07:53:06PM +0100, Arnd Bergmann wrote:
> > > On Mon, Jan 25, 2021 at 4:48 PM Alessio Balsini
> > > wrote:
> > > >
> >
> > Thanks for spotting this
On Fri, Mar 19, 2021 at 03:58:07PM +0100, Borislav Petkov wrote:
> On Fri, Mar 19, 2021 at 11:38:44AM -, tip-bot2 for Dave Hansen wrote:
> > tools/testing/selftests/sgx/load.c | 66 ++---
> > tools/testing/selftests/sgx/main.c | 2 +-
> > 2 files changed, 53
On 19-03-21, 15:35, Rafael J. Wysocki wrote:
> On Friday, March 19, 2021 8:37:51 AM CET Viresh Kumar wrote:
> > On 18-03-21, 22:28, Peter Zijlstra wrote:
> > > Also, is there a lock order comment in cpufreq somewhere?
> >
> > I don't think so.
> >
> > > I tried
> > > following it, but eventually
On Mon, 15 Mar 2021 at 20:18, Valentin Schneider
wrote:
>
> On 15/03/21 16:13, Vincent Guittot wrote:
> > On Thu, 11 Mar 2021 at 13:05, Valentin Schneider
> > wrote:
> >>
> >> Consider the following (hypothetical) asymmetric CPU capacity topology,
> >> with some amount of capacity pressure (RT |
[This email landed to Spam for some reason, sending it again with modified
subject]
While building arm64 kernel modules the following kernel warnings /
errors noticed on linux next 20210318 tag the gcc version is 7.3.0.
Build PASS with gcc-8, gcc-9 and gcc-10.
In file included from :0:0:
In
On Fri, Mar 19, 2021 at 07:40:21AM -0500, Alex Elder wrote:
> On 3/19/21 12:00 AM, Leon Romanovsky wrote:
> > On Thu, Mar 18, 2021 at 11:29:23PM -0500, Alex Elder wrote:
> > > Convert some commented assertion statements into real calls to
> > > ipa_assert(). If the IPA device pointer is
On 3/19/21 12:21 AM, Daniel Borkmann wrote:
On 3/19/21 3:11 AM, Piotr Krysiuk wrote:
Hi Daniel,
On Fri, Mar 19, 2021 at 12:16 AM Stephen Rothwell
wrote:
diff --cc kernel/bpf/verifier.c
index 44e4ec1640f1,f9096b049cd6..
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
On Fri, Mar 19, 2021 at 10:22:54AM +0100, Peter Zijlstra wrote:
> @@ -814,6 +814,11 @@ struct section *elf_create_reloc_section
> }
> }
>
> +static inline bool is_reloc_section(struct section *reloc)
> +{
> + return reloc->base && reloc->base->reloc == reloc;
> +}
I believe the 2nd
On 3/19/2021 2:28 AM, Borislav Petkov wrote:
On Thu, Mar 18, 2021 at 12:05:58PM -0700, Yu, Yu-cheng wrote:
Maybe I would add comments here.
Yap.
Also, looking forward in the set, I see prctl_set() and that is also
done on current so should be ok.
In any case, yes, documenting the
On Fri, 19 Mar 2021, Greg Kroah-Hartman wrote:
> > > diff --git a/drivers/net/bonding/bond_main.c
> > > b/drivers/net/bonding/bond_main.c
> > > index 5fe5232cc3f3..fba6b6d1b430 100644
> > > --- a/drivers/net/bonding/bond_main.c
> > > +++ b/drivers/net/bonding/bond_main.c
> > > @@ -3917,11
On Fri, Mar 19, 2021 at 10:47:36AM +0100, Peter Zijlstra wrote:
> Full patch, because diff on a diff on a diff is getting ludicrous hard
> to read :-)
Appreciated :-)
> -void elf_add_reloc(struct elf *elf, struct reloc *reloc)
> +int elf_add_reloc(struct elf *elf, struct section *sec, unsigned
Hi,
On Mon, Mar 15, 2021 at 6:15 PM Matthias Kaehlcke wrote:
>
> The only kernel visible change with respect to rev2 is that pompom
> rev3 changed the charger thermistor from a 47k to a 100k NTC to use
> a thermistor which is supported by the PM6150 ADC driver.
>
> Disable the charger thermal
On Fri, Mar 19, 2021 at 05:19:47PM +0300, Dmitry Osipenko wrote:
> 19.03.2021 16:51, Dmitry Osipenko пишет:
> > 19.03.2021 16:47, Greg Kroah-Hartman пишет:
> >> On Fri, Mar 19, 2021 at 04:45:21PM +0300, Dmitry Osipenko wrote:
> >>> 19.03.2021 16:42, Greg Kroah-Hartman пишет:
> On Fri, Mar 19,
On Fri, Mar 19, 2021 at 03:12:12PM +0100, Jiri Kosina wrote:
> On Fri, 19 Mar 2021, Greg Kroah-Hartman wrote:
>
> > From: Jia-Ju Bai
> >
> > [ Upstream commit 2055a99da8a253a357bdfd359b3338ef3375a26c ]
> >
> > When slave is NULL or slave_ops->ndo_neigh_setup is NULL, no error
> > return code
On Fri, Mar 19, 2021 at 03:24:38PM +0100, Jiri Kosina wrote:
> On Fri, 19 Mar 2021, Jiri Kosina wrote:
>
> > > [ Upstream commit 2055a99da8a253a357bdfd359b3338ef3375a26c ]
> > >
> > > When slave is NULL or slave_ops->ndo_neigh_setup is NULL, no error
> > > return code of bond_neigh_init() is
On 3/18/2021 8:12 PM, Bart Van Assche wrote:
On 3/18/21 5:35 PM, Asutosh Das wrote:
During runtime-suspend of ufs host, the scsi devices are
already suspended and so are the queues associated with them.
But the ufs host sends SSU to wlun during its runtime-suspend.
During the process
On 2021-03-19 10:22 a.m., Alex Deucher wrote:
On Fri, Mar 19, 2021 at 3:23 AM Evan Benn wrote:
AMDGPU_DM_DEFAULT_MIN_BACKLIGHT was set to the value of 12
to ensure no display backlight will flicker at low user brightness
settings. However this value is quite bright, so for devices that do
Hey Chuck,
Thanks for the (very) fast reply! :-)
Chuck Lever III writes:
This can be confusing for downstream users, who don't know what messages
like "fragment too large: 1195725856" actually mean, or that they
indicate some misconfigured infrastructure elsewhere.
One wonders whether that
Hi Yanan,
Sorry for taking so long to reply, been busy with other things unfortunately. I
did notice that you sent a new version of this series, but I would like to
continue our discussion on this patch, since it's easier to get the full
context.
On 3/4/21 7:07 AM, wangyanan (Y) wrote:
> Hi
With commit f8425c939663 ("fuse: 32-bit user space ioctl compat for fuse
device") the matching constraints for the FUSE_DEV_IOC_CLONE ioctl
command are relaxed, limited to the testing of command type and number.
As Arnd noticed, this is wrong as it wouldn't ensure the correctness of
the data size
On Fri, Mar 19, 2021 at 12:09:34PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 19, 2021 at 10:09 AM Johan Hovold wrote:
> > > I think it is almost always wrong to call spin_lock_irqsave in
> > > hardirq.
> >
> > Again, no. It's even been a requirement due to "threadirqs" in some
> > cases (e.g.
On Wed, Mar 17, 2021 at 9:27 AM Yang Li wrote:
>
> This fixes the following sparse warnings:
> drivers/gpu/drm/gma500/psb_drv.c:303:56: warning: Using plain integer as
> NULL pointer
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
Applied to drm-misc-next
Thanks
Patrik
> ---
>
On Fri, Mar 19, 2021 at 10:54:05AM +0100, Peter Zijlstra wrote:
> On Thu, Mar 18, 2021 at 09:14:03PM -0500, Josh Poimboeuf wrote:
> > On Thu, Mar 18, 2021 at 06:11:13PM +0100, Peter Zijlstra wrote:
> > > Create a common helper to add symbols.
> > >
> > > Signed-off-by: Peter Zijlstra (Intel)
> >
On (21/03/19 18:12), Yafang Shao wrote:
>
> The existed pGp shows the names of page flags only, rather than the full
> information including section, node, zone, last cpuipid and kasan tag.
> While it is not easy to parse these information manually because there
> are so many flavors. We'd better
On 3/19/21 9:40 AM, Madhavan T. Venkataraman wrote:
>> Are you referring to ARMv8.1 VHE extension where the kernel can run
>> at EL2? Could you elaborate? I thought that EL2 was basically for
>> Hypervisors.
> KVM is the main case, yes - IIRC otherwise it's mainly error handlers
> but I might
Hey folks,
Let me know if you'd like more evidence that this is a persisting problem. Also
more than happy to change the generation of the whole debug string to go into
svc_sock_reclen_ascii or use LOG_CONT if you'd prefer to avoid the multiple
ternaries (but the latter probably needs some
Hello Hans
On Fri, Mar 19, 2021 at 9:35 AM Hans Verkuil wrote:
>
> On 18/03/2021 21:29, Ricardo Ribalda wrote:
> > Take a v4l2_ext_controls instead of an array of controls, this way we
> > can access the error_idx in future changes.
> >
> > Signed-off-by: Ricardo Ribalda
> > ---
> >
On a typical end product, a vendor may choose to secure some regions in
the NAND memory which are supposed to stay intact between FW upgrades.
The access to those regions will be blocked by a secure element like
Trustzone. So the normal world software like Linux kernel should not
touch these
On a typical end product, a vendor may choose to secure some regions in
the NAND memory which are supposed to stay intact between FW upgrades.
The access to those regions will be blocked by a secure element like
Trustzone. So the normal world software like Linux kernel should not
touch these
Convert Qcom NANDc devicetree binding to YAML.
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Rob Herring
---
.../devicetree/bindings/mtd/qcom,nandc.yaml | 196 ++
.../devicetree/bindings/mtd/qcom_nandc.txt| 142 -
2 files changed, 196 insertions(+), 142
On a typical end product, a vendor may choose to secure some regions in
the NAND memory which are supposed to stay intact between FW upgrades.
The access to those regions will be blocked by a secure element like
Trustzone. So the normal world software like Linux kernel should not
touch these
On Fri, Mar 19, 2021 at 04:50:33PM +0200, Jarkko Sakkinen wrote:
> > > I was on the verge whether to merge that into the original patch since
> > > it is the top patch on the branch or create a new one but opted for
> > > former because this way it won't break bisection and people won't have
> > >
Hi Chris-
> On Mar 19, 2021, at 10:54 AM, Chris Down wrote:
>
> The reclen is taken directly from the first four bytes of the message
> with the highest bit stripped, which makes it ripe for protocol mixups.
> For example, if someone tries to send a HTTP GET request to us, we'll
> interpret it
On Fri, Mar 19, 2021 at 11:38:44AM -, tip-bot2 for Dave Hansen wrote:
> tools/testing/selftests/sgx/load.c | 66 ++---
> tools/testing/selftests/sgx/main.c | 2 +-
> 2 files changed, 53 insertions(+), 15 deletions(-)
Anything against some more tweaks ontop?
---
diff
On Fri, Mar 12, 2021 at 11:57 AM Lee Jones wrote:
>
> [P_RETRY_WRITE] is initialised more than once.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/block/drbd/drbd_main.c: In function ‘cmdname’:
> drivers/block/drbd/drbd_main.c:3660:22: warning: initialized field
>
The reclen is taken directly from the first four bytes of the message
with the highest bit stripped, which makes it ripe for protocol mixups.
For example, if someone tries to send a HTTP GET request to us, we'll
interpret it as a 1195725856-sized fragment (ie. (u32)'GET '), and print
a ratelimited
On Fri, Mar 19, 2021 at 3:36 PM David Hildenbrand wrote:
> Since /dev/kmem has been removed, let's remove the xlate_dev_kmem_ptr()
> leftovers.
> Signed-off-by: David Hildenbrand
> arch/m68k/include/asm/io_mm.h | 5 -
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
The error handling in ksmbd_server_init() uses "one function to free
everything style" which is impossible to audit and leads to several
canonical bugs. When we free something that wasn't allocated it may be
uninitialized, an error pointer, freed in a different function or we
try freeing
Hi Laurent,
On Fri, Mar 19, 2021 at 02:29:30AM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Wed, Mar 17, 2021 at 11:04:45AM +0100, Jacopo Mondi wrote:
> > On Mon, Mar 15, 2021 at 05:22:37PM +, Kieran Bingham wrote:
> > > On 15/03/2021 13:15, Jacopo Mondi wrote:
> > > > It has been
On (21/03/19 11:43), Petr Mladek wrote:
>
> The patch is comitted in printk/linux.git, branch for-5.13.
Thanks.
> Now I have to remember using the new address, for example, when
> calling git send-email from bash history ;-)
:)
On Fri, Mar 19, 2021 at 08:29:27PM +1300, Kai Huang wrote:
> This series adds KVM SGX virtualization support. The first 14 patches starting
> with x86/sgx or x86/cpu.. are necessary changes to x86 and SGX core/driver to
> support KVM SGX virtualization, while the rest are patches to KVM subsystem.
On Fri, Mar 19, 2021 at 10:01:41PM +1300, Kai Huang wrote:
> On Fri, 19 Mar 2021 09:45:23 +0100 Borislav Petkov wrote:
> > On Fri, Mar 19, 2021 at 05:06:02PM +1300, Kai Huang wrote:
> > > Below kernel bug happened when running simple SGX application when EPC
> > > is under pressure. The root
On Fri, Mar 19, 2021 at 09:45:23AM +0100, Borislav Petkov wrote:
> On Fri, Mar 19, 2021 at 05:06:02PM +1300, Kai Huang wrote:
> > Below kernel bug happened when running simple SGX application when EPC
> > is under pressure. The root cause is with commit 5b8719504e3a
> > ("x86/sgx: Add a basic
From: "Rafael J. Wysocki"
Revert commit 44cc89f76464 ("PM: runtime: Update device status
before letting suppliers suspend") that introduced a race condition
into __rpm_callback() which allowed a concurrent rpm_resume() to
run and resume the device prematurely after its status had been
changed to
From: Rafael J. Wysocki
Because the PM-runtime status of the device is not updated in
__rpm_callback(), attempts to suspend the suppliers of the given
device triggered by the rpm_put_suppliers() call in there may
cause a supplier to be suspended completely before the status of
the consumer is
On Thursday, March 18, 2021 7:06:54 PM CET Rafael J. Wysocki wrote:
> Hi All,
>
> The previous attempt to address the issue tackled by this series, commit
> 44cc89f76464 ("PM: runtime: Update device status before letting suppliers
> suspend") was incorrect, because it introduced a rather nasty
On Fri, 19 Mar 2021 at 04:34, Suzuki K Poulose wrote:
>
> Hi Mathieu,
>
> > On 18 Mar 2021, at 18:08, Mathieu Poirier
> > wrote:
> >
> > Good morning,
> >
> > On Thu, Feb 25, 2021 at 07:35:42PM +, Suzuki K Poulose wrote:
> >> From: Anshuman Khandual
> >>
> >> Trace Buffer Extension (TRBE)
Hi Valentin!
On 3/18/21 2:06 PM, Valentin Schneider wrote:
> John Paul reported a warning about bogus NUMA distance values spurred by
> commit:
>
> 620a6dc40754 ("sched/topology: Make sched_init_numa() use a set for the
> deduplicating sort")
>
> In this case, the afflicted machine comes up
If the kasprintf() allocation fails after the first iteration through
the loop then it returns success instead of -ENOMEM as intended.
Fixes: bcfdf8afdebe ("stm class: dummy_stm: Create multiple devices")
Signed-off-by: Dan Carpenter
---
drivers/hwtracing/stm/dummy_stm.c | 6 --
1 file
Am Fri, 19 Mar 2021 15:41:44 +0100
schrieb Olaf Hering :
> FullyQualifiedDomainName
I think in the past I did asked MSFT what the host side really expects. Maybe
this time there will be an answer.
Why would the host expect a FQDN from a VM? Why would it care about DNS layout
of the network
On 19.03.21 15:34, David Hildenbrand wrote:
Let's start a discussion if /dev/kmem is worth keeping around and
fixing/maintaining or if we should just remove it now for good.
More details / findings in patch #1. Patch #2 and #3 perform minor cleanups
based on removed /dev/kmem support.
As some
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote:
>
> Just another drive-by fix I noticed while going through the tree to cleanup
> DP aux adapter registration - make sure we unregister the DP AUX dev if
>
Basically the TI TSC2046 touchscreen controller is 8 channel ADC optimized for
the touchscreen use case. By implementing it as an IIO ADC device, we can
make use of resistive-adc-touch and iio-hwmon drivers.
So far, this driver was tested with a custom version of resistive-adc-touch
driver,
Add a binding documentation for the TI TSC2046 touchscreen controllers
ADC functionality.
Signed-off-by: Oleksij Rempel
Reviewed-by: Rob Herring
---
.../bindings/iio/adc/ti,tsc2046.yaml | 115 ++
1 file changed, 115 insertions(+)
create mode 100644
Settling time and over sampling is a typical challenge for different IIO ADC
devices. So, introduce channel specific settling-time-us and oversampling-ratio
properties to cover this use case.
Signed-off-by: Oleksij Rempel
---
Documentation/devicetree/bindings/iio/adc/adc.yaml | 9 +
1
changes v3:
- different spell fixes
- add some notes about driver structure
- rename the trigger to point on the touchscreen nature of it
- rename DT binding to oversampling-ratio
- make sure we have some defaults in case no DT property is set
changes v2:
- rework and extend DT binding properties
The hostname is resolved just once since commit 58125210ab3b ("Tools:
hv: cache FQDN in kvp_daemon to avoid timeouts") to make sure the VM
responds within the timeout limits to requests from the host.
If for some reason getaddrinfo fails, the string returned by the
"FullyQualifiedDomainName"
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote:
>
> Another drive-by fix I found when fixing DP AUX adapter across the kernel
> tree - make sure we don't leak resources (and by proxy-AUX adapters) on
> failures in
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote:
>
> Another case of linking an encoder to a connector after the connector's
> been registered. The proper place to do this is before connector
> registration, so
fix the following checkpatch.pl issues:
WARNING: Unnecessary ftrace-like logging - prefer using ftrace
Signed-off-by: Paul McQuade
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
KASAN is supported on 32-bit powerpc and the docs should reflect this.
Suggested-by: Christophe Leroy
Reviewed-by: Christophe Leroy
Signed-off-by: Daniel Axtens
---
Documentation/dev-tools/kasan.rst | 8 ++--
Documentation/powerpc/kasan.txt | 12
2 files changed, 18
kasan is already implied by the directory name, we don't need to
repeat it.
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
---
arch/powerpc/mm/kasan/Makefile | 2 +-
arch/powerpc/mm/kasan/{kasan_init_32.c => init_32.c} | 0
2 files changed, 1 insertion(+), 1
Implement a limited form of KASAN for Book3S 64-bit machines running under
the Radix MMU, supporting only outline mode.
- Enable the compiler instrumentation to check addresses and maintain the
shadow region. (This is the guts of KASAN which we can easily reuse.)
- Require kasan-vmalloc
For annoying architectural reasons, it's very difficult to support inline
instrumentation on powerpc64.
Add a Kconfig flag to allow an arch to disable inline. (It's a bit
annoying to be 'backwards', but I'm not aware of any way to have
an arch force a symbol to be 'n', rather than 'y'.)
We also
Allow architectures to define a kasan_arch_is_ready() hook that bails
out of any function that's about to touch the shadow unless the arch
says that it is ready for the memory to be accessed. This is fairly
uninvasive and should have a negligible performance penalty.
This will only work in
powerpc has a variable number of PTRS_PER_*, set at runtime based
on the MMU that the kernel is booted under.
This means the PTRS_PER_* are no longer constants, and therefore
breaks the build.
Define default MAX_PTRS_PER_*s in the same style as MAX_PTRS_PER_P4D.
As KASAN is the only user at the
On 19/03/2021 15.13, Peter Zijlstra wrote:
>> Dunno, probably overkill, but perhaps we could have an atomic_t (or
>> refcount, whatever) init_ref inited to 1, with init_ref_get() doing an
>> inc_unless_zero, and iff you get a ref, you're free to call (/patch)
>> __init functions and access
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to 64-bit Book3S kernels running on the Radix MMU.
v11 applies to next-20210317. I had hoped to have it apply to
powerpc/next but once again there are changes in the kasan core that
clash. Also, thanks to mpe for fixing a
On 3/19/21 8:22 AM, Mark Brown wrote:
> On Thu, Mar 18, 2021 at 05:22:49PM -0500, Madhavan T. Venkataraman wrote:
>> On 3/18/21 12:40 PM, Mark Brown wrote:
>
>>> Unless I'm misreading what's going on here this is more trying to set a
>>> type for the stack as a whole than for a specific stack
On 18/03/2021 14:50, Bjorn Andersson wrote:
On Mon 15 Mar 07:01 CDT 2021, Bryan O'Donoghue wrote:
On 12/03/2021 00:33, Bjorn Andersson wrote:
Enable the modem and WiFi subsystems and specify msm8916 specific
firmware path for these and the WCNSS control service.
Signed-off-by: Bjorn
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:58, Lyude Paul wrote:
>
> Another driver I found that seems to forget to unregister it's DP AUX
> device. Let's fix this by adding anx6345_bridge_detach().
>
> Signed-off-by: Lyude Paul
>
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Just another issue I noticed while correcting usages of
> drm_dp_aux_init()/drm_dp_aux_register() around the tree. If any of the
> steps in
The last user (/dev/kmem) is gone. Let's drop it.
Cc: Andrew Morton
Cc: Hillf Danton
Cc: Michal Hocko
Cc: Matthew Wilcox
Cc: Oleksiy Avramchenko
Cc: Steven Rostedt
Cc: Minchan Kim
Cc: huang ying
Signed-off-by: David Hildenbrand
---
include/linux/vmalloc.h | 1 -
mm/vmalloc.c
Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and
memory ballooning, I started questioning the existance of /dev/kmem.
Comparing it with the /proc/kcore implementation, it does not seem to be
able to deal with things like
a) Pages unmapped from the direct mapping (e.g., to
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Since encoder mappings for connectors are exposed to userspace, we should
> be attaching the encoder before exposing the connector to userspace. Just a
> drive-by
Since /dev/kmem has been removed, let's remove the xlate_dev_kmem_ptr()
leftovers.
Cc: Richard Henderson
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: Russell King
Cc: Brian Cain
Cc: Geert Uytterhoeven
Cc: Thomas Bogendoerfer
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: Michael Ellerman
On Friday, March 19, 2021 8:37:51 AM CET Viresh Kumar wrote:
> On 18-03-21, 22:28, Peter Zijlstra wrote:
> > Also, is there a lock order comment in cpufreq somewhere?
>
> I don't think so.
>
> > I tried
> > following it, but eventually gave up and figured 'asking' lockdep was
> > far simpler.
>
It is a hard error if a return value is ignored.
In case the return value has no meaning, remove the attribute.
Signed-off-by: Olaf Hering
---
v2:
resend
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a28bb374663d..9b7def6db494 100644
Let's start a discussion if /dev/kmem is worth keeping around and
fixing/maintaining or if we should just remove it now for good.
More details / findings in patch #1. Patch #2 and #3 perform minor cleanups
based on removed /dev/kmem support.
Only compile-tested on x86-64 -- good enough for
Hi Robin,
On 19/03/2021 13:17, Robin Murphy wrote:
> On 2021-03-19 11:05, Daniel Lezcano wrote:
>> The DTPM framework is looking for upstream SoC candidates to share the
>> power numbers.
>>
>> We can see around different numbers but the one which seems to be
>> consistent with the initial post
On Fri, Mar 19, 2021 at 3:12 PM Alexander A Sverdlin
wrote:
>
> From: Alexander Sverdlin
>
> There are several implementations of PL061 which lack GPIOINTR signal in
> hardware and only have individual GPIOMIS[7:0] interrupts. Use the
> hierarchical interrupt support of the gpiolib in these
On Fri, Mar 19, 2021 at 05:59:50PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Warning: Some of the branches in linux-next may still based on v5.12-rc1,
> so please be careful if you are trying to bisect a bug.
>
> News: if your -next included tree is based on Linus' tree tag
>
Hi Aswath,
On 19/03/21 1:30 pm, Aswath Govindraju wrote:
> From: Kishon Vijay Abraham I
>
> Add SERDES DT node for the single one lane SERDES present in
> AM64.
>
> Signed-off-by: Kishon Vijay Abraham I
> Signed-off-by: Aswath Govindraju
> ---
> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 52
On 3/19/21 7:30 AM, Mark Brown wrote:
> On Thu, Mar 18, 2021 at 03:26:13PM -0500, Madhavan T. Venkataraman wrote:
>> On 3/18/21 10:09 AM, Mark Brown wrote:
>
>>> If we are going to add the extra record there would probably be less
>>> potential for confusion if we pointed it at some sensibly
Hey Lyude,
Thanks for the patch, it looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Surprisingly, this bridge actually registers it's AUX adapter at the
> correct time already. Nice job! However, it does forget to actually
> unregister the AUX
Hey Lyude,
This patch looks good to me.
Reviewed-by: Robert Foss
On Fri, 19 Feb 2021 at 22:56, Lyude Paul wrote:
>
> Since this is a bridge, we don't start out with a respective DRM device.
> Likewise this means we don't have a connector, which also means that we
> should be following
On Fri, 19 Mar 2021, Jiri Kosina wrote:
> > [ Upstream commit 2055a99da8a253a357bdfd359b3338ef3375a26c ]
> >
> > When slave is NULL or slave_ops->ndo_neigh_setup is NULL, no error
> > return code of bond_neigh_init() is assigned.
> > To fix this bug, ret is assigned with -EINVAL in these cases.
On Fri, Mar 19, 2021 at 3:23 AM Evan Benn wrote:
>
> AMDGPU_DM_DEFAULT_MIN_BACKLIGHT was set to the value of 12
> to ensure no display backlight will flicker at low user brightness
> settings. However this value is quite bright, so for devices that do not
> implement the ACPI ATIF
>
19.03.2021 16:51, Dmitry Osipenko пишет:
> 19.03.2021 16:47, Greg Kroah-Hartman пишет:
>> On Fri, Mar 19, 2021 at 04:45:21PM +0300, Dmitry Osipenko wrote:
>>> 19.03.2021 16:42, Greg Kroah-Hartman пишет:
On Fri, Mar 19, 2021 at 04:39:41PM +0300, Dmitry Osipenko wrote:
> 19.03.2021 15:44,
On 3/19/21 8:49 AM, Vivek Goyal wrote:
On Thu, Mar 18, 2021 at 08:52:22AM -0500, Connor Kuehl wrote:
If an incoming FUSE request can't fit on the virtqueue, the request is
placed onto a workqueue so a worker can try to resubmit it later where
there will (hopefully) be space for it next time.
On 2021/03/12 0:54, Marco Elver wrote:
>> But the more we could have the compiler automatically figure out
>> things without needing an explicit tag, it would seem to me that this
>> would be better, since manual tagging is going to be more error-prone.
>
> What you're alluding to here would go
Hi Maninder,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on v5.12-rc3 next-20210319]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
On Fri, 19 Mar 2021, Campion Kang wrote:
>
> Please check [Campion] text in below as my reply.
This is a mess. Please setup your mailer to quote correctly.
> Sorry, due to the mail was rejected by vger.kernel.org as SPAM before
> so I reply the mail late and had some test email before.
>
>
On Fri, Mar 19, 2021 at 02:31:19PM +0100, Rasmus Villemoes wrote:
> On 18/03/2021 12.31, Peter Zijlstra wrote:
> > The intent is to avoid writing init code after init (because the text
> > might have been freed). The code is needlessly different between
> > jump_label and static_call and not
On Wed, 17 Mar 2021 at 00:20, Liming Sun wrote:
>
> This commit adds ACPI support in the sdhci-of-dwcmshc driver for
> BlueField-3 SoC. It has changes to only use the clock hierarchy
> for Deviec Tree since the clk is not supported by ACPI. Instead,
> ACPI can define 'clock-frequency' which is
On Fri, 19 Mar 2021 at 03:36, Seiya Wang wrote:
>
> This commit adds dt-binding documentation of mmc for Mediatek MT8195 SoC
> Platform.
>
> Signed-off-by: Seiya Wang
Applied for next, thanks!
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/mtk-sd.yaml | 1 +
> 1 file
701 - 800 of 1542 matches
Mail list logo
