etc ...
The 'thermal' prefix is redundant with the subsystem namespace. This
patch removes the 'thermal prefix and changes the number by the device
name. So the naming above becomes:
cpufreq-cpu0
cpufreq-cpu4
etc ...
Signed-off-by: Daniel Lezcano
---
drivers/thermal/cpufreq_cooling.c | 28
thermal-idle-2
thermal-idle-3
etc ...
The 'thermal' prefix is redundant with the subsystem namespace. This
patch removes the 'thermal prefix and changes the number by the device
name. So the naming above becomes:
idle-cpu0
idle-cpu1
idle-cpu2
idle-cpu3
etc ...
Signed-off-by: Daniel Lezcano
-by: Daniel Lezcano
Reviewed-by: Lukasz Luba
---
drivers/powercap/dtpm.c | 4 ++--
drivers/powercap/dtpm_cpu.c | 4 +++-
include/linux/dtpm.h| 22 +-
3 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/powercap/dtpm.c b/drivers/powercap
to reflect their purpose.
Signed-off-by: Daniel Lezcano
---
V2:
- Fixed error code path by dropping lock
---
drivers/powercap/dtpm.c | 161 ++--
drivers/powercap/dtpm_cpu.c | 4 +-
include/linux/dtpm.h| 12 ++-
3 files changed, 164 insertions(+), 13
ange:
~$ ~/dhrystone -t 1 -l 1&
~$ cat
/sys/devices/virtual/powercap/dtpm/dtpm:0/dtpm:0:1/constraint_0_max_power_uw
113
~$ ~/dhrystone -t 2 -l 1&
~$ cat
/sys/devices/virtual/powercap/dtpm/dtpm:0/dtpm:0:1/constraint_0_max_power_uw
226
Signed-off-by: Daniel Lezcano
---
V
allocating the device specific dtpm
structure. The dtpm_init() is provided instead.
Signed-off-by: Daniel Lezcano
Reviewed-by: Lukasz Luba
---
drivers/powercap/dtpm.c | 27 ++
drivers/powercap/dtpm_cpu.c | 46 ++---
include/linux/dtpm.h| 3
-by: Daniel Lezcano
---
V2:
- Updated the changelog with the CPU node not being removed
- Commented the cpu hotplug callbacks to explain why there are two callbacks
- Changed 'upt_power_uw' to 'update_power_uw'
- Removed unused cpumask variable
---
drivers/powercap/dtpm.c | 54
Hi Mark-PK,
On Mon, 8 Mar 2021 at 23:30, Mark-PK Tsai wrote:
> From: Daniel Palmer
> >On Mon, 8 Mar 2021 at 15:05, Mark-PK Tsai wrote:
> >> +static int mst_irq_chip_set_type(struct irq_data *data, unsigned int type)
> > > +{
> >> + if
-by: Daniel Lezcano
---
V2:
- Updated the changelog with the CPU node not being removed
- Commented the cpu hotplug callbacks to explain why there are two callbacks
- Changed 'upt_power_uw' to 'update_power_uw'
- Removed unused cpumask variable
---
drivers/powercap/dtpm.c | 54
allocating the device specific dtpm
structure. The dtpm_init() is provided instead.
Signed-off-by: Daniel Lezcano
Reviewed-by: Lukasz Luba
---
drivers/powercap/dtpm.c | 27 ++
drivers/powercap/dtpm_cpu.c | 46 ++---
include/linux/dtpm.h| 3
-by: Daniel Lezcano
Reviewed-by: Lukasz Luba
---
drivers/powercap/dtpm.c | 4 ++--
drivers/powercap/dtpm_cpu.c | 4 +++-
include/linux/dtpm.h| 22 +-
3 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/powercap/dtpm.c b/drivers/powercap
to reflect their purpose.
Signed-off-by: Daniel Lezcano
---
V2:
- Fixed error code path by dropping lock
---
drivers/powercap/dtpm.c | 161 ++--
drivers/powercap/dtpm_cpu.c | 4 +-
include/linux/dtpm.h| 12 ++-
3 files changed, 164 insertions(+), 13
ange:
~$ ~/dhrystone -t 1 -l 1&
~$ cat
/sys/devices/virtual/powercap/dtpm/dtpm:0/dtpm:0:1/constraint_0_max_power_uw
113
~$ ~/dhrystone -t 2 -l 1&
~$ cat
/sys/devices/virtual/powercap/dtpm/dtpm:0/dtpm:0:1/constraint_0_max_power_uw
226
Signed-off-by: Daniel Lezcano
---
V2:
On Tue, Mar 09, 2021 at 08:56:47AM +0100, Christophe Leroy wrote:
>
>
> Le 09/03/2021 à 01:02, Daniel Walker a écrit :
> > This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
> > option.
> >
> > Cc: xe-linux-exter...@cisco.com
> > Signed-off
Hi Masami,
Just want to clarify a few points:
On Mon, Mar 08, 2021 at 11:52:10AM +0900, Masami Hiramatsu wrote:
> On Sun, 7 Mar 2021 13:23:33 -0800
> Daniel Xu wrote:
> To help your understanding, let me explain.
>
> If we have a code here
>
> caller_func:
> 0x00
On Tue, Mar 09, 2021 at 08:47:09AM +0100, Christophe Leroy wrote:
>
>
> Le 09/03/2021 à 01:02, Daniel Walker a écrit :
> > This is a scripted mass convert of the config files to use
> > the new generic cmdline. There is a bit of a trim effect here.
> > It would se
From: panda
crypto_aead_encrypt returns <0 on error, so if these calls are not checked,
execution may continue with failed encrypts. It also seems that these two
crypto_aead_encrypt calls are the only instances in the codebase that are
not checked for errors.
Signed-off-by: Daniel P
On 09/03/2021 11:01, Lukasz Luba wrote:
> Hi Daniel,
>
> I've started reviewing the series, please find some comments below.
>
> On 3/1/21 9:21 PM, Daniel Lezcano wrote:
>> Currently the power consumption is based on the current OPP power
>> assuming the entire perform
Hi Lukasz,
thanks for your comments, one question below.
On 09/03/2021 11:01, Lukasz Luba wrote:
[ ... ]
>> +static u64 scale_pd_power_uw(struct cpumask *cpus, u64 power)
>
> renamed 'cpus' into 'pd_mask', see below
>
>> +{
>> + unsigned long max, util;
>> + int cpu, load = 0;
>
>
From: Daniel Baluta
Platform may be specified by either name or OF node but not
both.
For OF node platforms (e.g i.MX) we end up with both platform name
and of_node set and sound card registration will fail with the error:
asoc-simple-card sof-sound-wm8960: ASoC: Neither/both
platform name
echo "Two arguments are needed."
exit 1
fi
mkdir $1
cp $2 $1/.config
sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g'
$1/.config
make ARCH=$1 O=$1 olddefconfig
make ARCH=$1 O=$1 savedefconfig
cp $1/defconfig $2
rm -Rf $1
Cc: xe-linux-exter...@cisco.com
Signed-of
This updates the mips code to use the CONFIG_GENERIC_CMDLINE
option.
This deletes the option for MIPS_CMDLINE_BUILTIN_EXTEND
and replaces the functionality with generic code.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel
This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
option.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel Walker
---
arch/powerpc/Kconfig| 37 +
arch/powerpc/kernel
This updates the x86 code to use the CONFIG_GENERIC_CMDLINE
option.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel Walker
---
arch/x86/Kconfig| 44 +
arch/x86/kernel/setup.c
system.
These were tested on all effected architectures.
Daniel Walker (7):
CMDLINE: add generic builtin command line
CMDLINE: drivers: of: ifdef out cmdline section
powerpc: convert config files to generic cmdline
CMDLINE: powerpc: convert to generic builtin command line
mips: convert
en
echo "Two arguments are needed."
exit 1
fi
mkdir $1
cp $2 $1/.config
sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g'
$1/.config
make ARCH=$1 O=$1 olddefconfig
make ARCH=$1 O=$1 savedefconfig
cp $1/defconfig $2
rm -Rf $1
Cc: xe-linux-exter...@c
...@cisco.com
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel Walker
---
include/linux/cmdline.h | 89 +
init/Kconfig| 68 +++
2 files changed, 157 insertions(+)
create mode 100644 include/linux/cmdline.h
diff --git
It looks like there's some seepage of cmdline stuff into
the generic device tree code. This conflicts with the
generic cmdline implementation so I remove it in the case
when that's enabled.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Daniel Walker
It looks like there's some seepage of cmdline stuff into
the generic device tree code. This conflicts with the
generic cmdline implementation so I remove it in the case
when that's enabled.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Daniel Walker
...@cisco.com
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel Walker
---
include/linux/cmdline.h | 89 +
init/Kconfig| 68 +++
2 files changed, 157 insertions(+)
create mode 100644 include/linux/cmdline.h
diff --git
system.
These were tested on all effected architectures.
Daniel Walker (7):
CMDLINE: add generic builtin command line
CMDLINE: drivers: of: ifdef out cmdline section
powerpc: convert config files to generic cmdline
CMDLINE: powerpc: convert to generic builtin command line
mips: convert
On 09/03/2021 00:38, Daniel Lezcano wrote:
> From: Enric Balletbo i Serra
>
> The Rockchip DMC (Dynamic Memory Interface) needs to access to the PMU
> general register files to know the DRAM type, so add a phandle to the
> syscon that manages these registers.
>
> Signed-off
From: Gaël PORTAY
Those DDR related defines do not exist. Replace their references with
their numerical constant.
Signed-off-by: Gaël PORTAY
Reviewed-by: Rob Herring
Signed-off-by: Daniel Lezcano
---
.../bindings/devfreq/rk3399_dmc.txt | 73 +--
1 file changed, 34
From: Lin Huang
Enable the DMC (Dynamic Memory Controller) and the DFI (DDR PHY
Interface) nodes on gru boards so we can support DDR DVFS.
Signed-off-by: Lin Huang
Signed-off-by: Enric Balletbo i Serra
Signed-off-by: Gaël PORTAY
Signed-off-by: Daniel Lezcano
---
.../dts/rockchip/rk3399-gru
From: Lin Huang
These are required to support DDR DVFS on rk3399 platform.
Signed-off-by: Lin Huang
Signed-off-by: Enric Balletbo i Serra
Signed-off-by: Gaël PORTAY
Signed-off-by: Daniel Lezcano
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 19 +++
1 file changed, 19
Signed-off-by: Gaël PORTAY
Acked-by: MyungJoo Ham
Signed-off-by: Daniel Lezcano
---
Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
b/Documentation/devicetree/bindings
On 08/03/2021 20:55, Lukasz Luba wrote:
> Hi Daniel,
>
> On 3/8/21 7:31 PM, Daniel Lezcano wrote:
>>
>> On 01/03/2021 22:21, Daniel Lezcano wrote:
>>> In order to increase the self-encapsulation of the dtpm generic code,
>>> the following changes are adding
On Sun, Mar 7, 2021 at 9:39 PM Andy Shevchenko
>>>> wrote:
>>>>> On Sun, Mar 7, 2021 at 3:36 PM Daniel Scally wrote:
>>>>>> On 22/02/2021 13:34, Andy Shevchenko wrote:
>>>>>>> On Mon, Feb 22, 2021 at 3:12 PM Daniel Scally
>>>>
Hi Rafael
On 08/03/2021 17:46, Rafael J. Wysocki wrote:
>> +void acpi_walk_dep_device_list(acpi_handle handle,
>> + int (*callback)(struct acpi_dep_data *, void
>> *),
>> + void *data)
>> +{
>> + struct acpi_dep_data *dep, *tmp;
>>
On 01/03/2021 22:21, Daniel Lezcano wrote:
> In order to increase the self-encapsulation of the dtpm generic code,
> the following changes are adding a power update ops to the dtpm
> ops. That allows the generic code to call directly the dtpm backend
> function to update the
().
Fix it up in vfio_pin_page_external(). Found by inspection.
Fixes: be16c1fd99f4 ("vfio/type1: Change success value of vaddr_get_pfn()")
Signed-off-by: Daniel Jordan
---
I couldn't test this due to lack of hardware.
drivers/vfio/vfio_iommu_type1.c | 8 +++-
1 file changed, 7 insert
his
patch, which fixed the problem for me.
Mine is an Armv8 system but there is nothing particularly exotic from a
graphics card or software point of view: Debian bullseye/wayland
(gnome-shell 3.38.3, mesa-20.3.4) running on a GT-710.
However FWIW:
Tested-by: Daniel Thompson
Daniel.
> ---
&
On 08/03/2021 14:49, Michael Kelley wrote:
> From: Michael Kelley Sent: Tuesday, March 2, 2021
> 3:07 PM
>>
>> From: Daniel Lezcano Sent: Tuesday, March 2,
>> 2021 2:14 PM
>>>
>>> On 02/03/2021 22:38, Michael Kelley wrote:
>>>> Whil
mean we can't do rising or falling edge interrupts?
Thanks,
Daniel
appears before
tools/include/uapi/linux/types.h then I say it is preferred.
Signed-off-by: Ian Rogers
Given more related to perf build infra, I presume Arnaldo would pick
this one up?
Thanks,
Daniel
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
Reviewed-by: Steven Price
---
drivers/gpu/drm
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devfreq.c | 14
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_gpu.c | 12
to register the newly created devfreq as
a cooling device.
Suggested-by: Chanwoo Choi
Signed-off-by: Daniel Lezcano
Reviewed-by: Steven Price
Reviewed-by: Lukasz Luba
---
V6:
- Did one line string instead of multiline
- Removed thermal.h header inclusion as it is in devfreq_cooling.h
- Added
GPIOs that are wired into the mstar intc
on the MStar/SigmaStar chips. I'll get back to you with how that works
out.
Thanks,
Daniel
>
> > The register values being lost if the chip goes into suspend to memory
> > makes sense for the MStar chips too I think as everything that is n
On 08/03/2021 10:53, Lukasz Luba wrote:
> Hi Daniel,
>
> In general the approach is good. If there is a special GPU driver, which
> would like to provide 'struct devfreq_cooling_power *' it would leave
> 'is_cooling_device=false' and register manually:
> devfreq_cooling_em_regi
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devfreq.c | 14
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_gpu.c | 12
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/panfrost
to register the newly created devfreq as
a cooling device.
Suggested-by: Chanwoo Choi
Signed-off-by: Daniel Lezcano
---
V5:
- Changed subject prefix by: PM / devfreq
V4:
- Replaced thermal_cooling_device_unregister() by
devfreq_cooling_unregister()
V3:
- Rebased on linux-pm branch
On Sat, Mar 06, 2021 at 10:13:57AM +0900, Masami Hiramatsu wrote:
> On Fri, 5 Mar 2021 11:16:45 -0800
> Daniel Xu wrote:
>
> > Hi Masami,
> >
> > On Sat, Mar 06, 2021 at 12:38:57AM +0900, Masami Hiramatsu wrote:
> > > Hello,
> > >
> > > H
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/panfrost
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devfreq.c | 14
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_gpu.c | 12
to register the newly created devfreq as
a cooling device.
Suggested-by: Chanwoo Choi
Signed-off-by: Daniel Lezcano
---
V4:
- Replaced thermal_cooling_device_unregister() by
devfreq_cooling_unregister()
V3:
- Rebased on linux-pm branch without units.h
- Set the cdev to NULL in case
On 07/03/2021 16:14, Chanwoo Choi wrote:
> On 21. 3. 7. 오후 11:28, Daniel Lezcano wrote:
[ ... ]
> Thanks. And, please add 'PM /' prefix for patch in order to
> keep the consistent patch title format.
>
> PM / devfreq: Register devfreq as a cooling device on demand
Sure, th
-by: Daniel Almeida
On 07/03/2021 15:16, Chanwoo Choi wrote:
> On 21. 3. 7. 오후 6:45, Daniel Lezcano wrote:
>> Currently the default behavior is to manually having the devfreq
>> backend to register themselves as a devfreq cooling device.
>>
>> Instead of adding the code in the driv
Hi Andy
On 22/02/2021 13:34, Andy Shevchenko wrote:
> On Mon, Feb 22, 2021 at 3:12 PM Daniel Scally wrote:
>> The acpi_walk_dep_device_list() is not as generalisable as its name
>> implies, serving only to decrement the dependency count for each
>> dependent device
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devfreq.c | 14
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/panfrost
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_gpu.c | 12
to register the newly created devfreq as
a cooling device.
Suggested-by: Chanwoo Choi
Signed-off-by: Daniel Lezcano
---
V3:
- Rebased on linux-pm branch without units.h
- Set the cdev to NULL in case of error
- Added description for the cdev field in the devfreq structure
V2:
- Added
if the chip goes into suspend to memory
makes sense for the MStar chips too I think as everything that is not
in the "pmsleep" register group seems to be lost.
Thanks,
Daniel
On 3/5/21 5:15 PM, Willem de Bruijn wrote:
On Fri, Mar 5, 2021 at 11:10 AM Daniel Borkmann wrote:
On 3/5/21 4:08 PM, Willem de Bruijn wrote:
On Fri, Mar 5, 2021 at 7:34 AM Xuesen Huang wrote:
From: Xuesen Huang
Add BPF_F_ADJ_ROOM_ENCAP_L2_ETH flag to the existing tests which
On Fri, Mar 05, 2021 at 01:32:44PM -0600, Josh Poimboeuf wrote:
> On Fri, Mar 05, 2021 at 11:25:15AM -0800, Daniel Xu wrote:
> > > BTW, is this a regression? or CONFIG_UNWINDER_ORC has this issue before?
> > > It seems that the above commit just changed the default unwind
On Fri, Mar 05, 2021 at 07:58:09PM +0900, Masami Hiramatsu wrote:
> On Fri, 5 Mar 2021 18:28:06 +0900
> Masami Hiramatsu wrote:
>
> > Hi Daniel,
> >
> > On Thu, 4 Mar 2021 16:07:52 -0800
> > Daniel Xu wrote:
> >
> > > Getting a stack trace
Hi Masami,
On Sat, Mar 06, 2021 at 12:38:57AM +0900, Masami Hiramatsu wrote:
> Hello,
>
> Here is a series of patches for kprobes and stacktracer to fix the kretprobe
> entries in the kernel stack. This was reported by Daniel Xu. I thought that
> was in the bpftrace, but it i
On 05/03/2021 18:24, man...@codeaurora.org wrote:
> On 2020-12-08 00:23, Manaf Meethalavalappu Pallikunhi wrote:
>
> Gentle reminder..
Thanks for the reminder, I'll pick it for the next -rc
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_gpu.c | 12
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/panfrost
to register the newly created devfreq as
a cooling device.
Suggested-by: Chanwoo Choi
Signed-off-by: Daniel Lezcano
---
drivers/devfreq/devfreq.c | 11 +++
include/linux/devfreq.h | 7 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devfreq.c | 14
On 3/5/21 4:08 PM, Willem de Bruijn wrote:
On Fri, Mar 5, 2021 at 7:34 AM Xuesen Huang wrote:
From: Xuesen Huang
Add BPF_F_ADJ_ROOM_ENCAP_L2_ETH flag to the existing tests which
encapsulates the ethernet as the inner l2 header.
Update a vxlan encapsulation test case.
Signed-off-by: Xuesen
t;
> wm8962 3-001a: Unsupported BCLK ratio 9
>
> Fix this by relaxing bitclk divider searching, so that when
> no exact value can be derived from sysclk pick the closest
> value greater than expected bitclk.
>
> Signed-off-by: Shengjiu Wang
Reviewed-by: Daniel Baluta
On 05/03/2021 09:12, Steven Price wrote:
> On 04/03/2021 12:50, Daniel Lezcano wrote:
>> Currently the default behavior is to manually having the devfreq
>> backend to register themselves as a devfreq cooling device.
>>
>> There are no so many and actually it m
call_64+51
entry_SYSCALL_64_after_hwframe+68
]: 12
Fixes: fc72ae40e303 ("x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in
kconfig for 64-bit")
Signed-off-by: Daniel Xu
---
arch/x86/kernel/unwind_orc.c | 53 +++-
kernel/kprobes.c
On Thu, Mar 04, 2021 at 08:09:52AM +0100, Christophe Leroy wrote:
>
>
> Le 04/03/2021 à 05:47, Daniel Walker a écrit :
> > It looks like there's some seepage of cmdline stuff into
> > the generic device tree code. This conflicts with the
> > generic cmdline
On Thu, Mar 04, 2021 at 08:00:49AM +0100, Christophe Leroy wrote:
>
>
> Le 04/03/2021 à 05:47, Daniel Walker a écrit :
> > This code allows architectures to use a generic builtin command line.
> > The state of the builtin command line options across architecture is
> &g
On Thu, Mar 04, 2021 at 08:32:37AM -0600, Rob Herring wrote:
> On Wed, Mar 3, 2021 at 10:48 PM Daniel Walker wrote:
> >
> > It looks like there's some seepage of cmdline stuff into
> > the generic device tree code. This conflicts with the
> > generic cmdline
On Wed, Mar 3, 2021, at 6:18 PM, Daniel Xu wrote:
> On Wed, Mar 03, 2021 at 03:37:40PM -0500, Steven Rostedt wrote:
> > On Wed, 03 Mar 2021 12:13:08 -0800
> > "Daniel Xu" wrote:
> >
> > > On Wed, Mar 3, 2021, at 11:58 AM, Daniel Xu wrote:
> > > &
On 04/03/2021 16:06, Chanwoo Choi wrote:
> Hi Daniel,
>
> As Lukasz's comment, actually some devfreq devices like memory bus
> might not affect the thermal critically. In the mainline,
> there are four types devfreq as following:
> 1. GPU
> 2. UFS Storage
> 3. DMC (Memory
Hi Lukasz,
thanks for commenting this patch,
On 04/03/2021 14:47, Lukasz Luba wrote:
> Hi Daniel,
>
> On 3/4/21 12:50 PM, Daniel Lezcano wrote:
>> Currently the default behavior is to manually having the devfreq
>> backend to register themselves as a d
Hi Hans
On 04/03/2021 13:37, Hans de Goede wrote:
> Hi,
>
> On 2/22/21 2:07 PM, Daniel Scally wrote:
>> v1 for this series was originally 14-18 of this series:
>> https://lore.kernel.org/linux-media/20201130133129.1024662-1-djrsca...@gmail.com/T/#m91934e12e3d033da2e768e952ea3
is.
Having a devfreq being registered as a cooling device can not mitigate
a thermal zone if it is not bound to this one. Thus, the current
configurations are not impacted by this change.
Signed-off-by: Daniel Lezcano
---
drivers/devfreq/devfreq.c | 8
drivers/gpu/drm
Hi Andrew,
On 04/03/2021 01:31, Andrew Morton wrote:
> On Wed, 24 Feb 2021 10:39:36 +0200 Andy Shevchenko
> wrote:
>
>> On Wednesday, February 24, 2021, Andy Shevchenko
>> wrote:
>>
>>>
>>>
>>> On Tuesday, February 23, 2021, Dani
On 04/03/2021 07:08, Sowjanya Komatineni wrote:
> Add Tegra CPUIDLE driver section with maintainers and mailing list
> entries.
>
> Signed-off-by: Sowjanya Komatineni
> ---
> MAINTAINERS | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index
This updates the x86 code to use the CONFIG_GENERIC_CMDLINE
option.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel Walker
---
arch/x86/Kconfig| 44 +
arch/x86/kernel/setup.c
It looks like there's some seepage of cmdline stuff into
the generic device tree code. This conflicts with the
generic cmdline implementation so I remove it in the case
when that's enabled.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Daniel Walker
This updates the mips code to use the CONFIG_GENERIC_CMDLINE
option.
This deletes the option for MIPS_CMDLINE_BUILTIN_EXTEND
and replaces the functionality with generic code.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel
...@cisco.com
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel Walker
---
include/linux/cmdline.h | 75 +
init/Kconfig| 68 +
2 files changed, 143 insertions(+)
create mode 100644 include/linux/cmdline.h
diff --git
This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
option.
Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko
Signed-off-by: Ruslan Bilovol
Signed-off-by: Daniel Walker
---
arch/powerpc/Kconfig| 37 +
arch/powerpc/kernel
On Wed, Mar 03, 2021 at 03:37:40PM -0500, Steven Rostedt wrote:
> On Wed, 03 Mar 2021 12:13:08 -0800
> "Daniel Xu" wrote:
>
> > On Wed, Mar 3, 2021, at 11:58 AM, Daniel Xu wrote:
> > > On Wed, Mar 03, 2021 at 09:26:04AM -0500, Steven Rostedt wrote:
> &g
On Wed, Mar 03, 2021 at 01:48:28PM +0900, Masami Hiramatsu wrote:
> Hi Daniel,
>
> On Tue, 02 Mar 2021 17:15:13 -0800
> "Daniel Xu" wrote:
>
> > Hi Masami,
> >
> > Jakub reported a bug with kretprobe stack traces -- wondering if you've
> > g
kernels now to check. Will report back.
<...>
Thanks,
Daniel
501 - 600 of 36717 matches
Mail list logo
