. This
is required for the source files present in drivers/of/unittest-data/,
because they can't be renamed to .dtso as they are used for some runtime
testing as well.
Reviewed-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Signed-off-by: Viresh Kumar
---
scripts/Makefile.lib | 9 -
1
o_base.dtb foo_overlay1.dtbo foo_overlay2.dtbo
dtb-y := foo.dtb
We don't want to run schema checks on foo.dtb (as foo.dts doesn't exist)
and the Makefile is updated accordingly.
Signed-off-by: Rob Herring
Co-developed-by: Viresh Kumar
Signed-off-by: Viresh Kumar
---
scripts/Makefil
We update 'extra-y' based on CONFIG_OF_ALL_DTBS three times. It would be
far more straight forward if we rather update dtb-y to include all .dtb
files if CONFIG_OF_ALL_DTBS is enabled.
Acked-by: Masahiro Yamada
Signed-off-by: Viresh Kumar
---
scripts/Makefile.lib | 5 ++---
1 file changed, 2
and slightly modified by me.
- Adapt Patch 3/3 to the new rule and name the overlay dtbs as .dtbo.
--
Viresh
Rob Herring (1):
kbuild: Add generic rule to apply fdtoverlay
Viresh Kumar (4):
kbuild: Simplify builds with CONFIG_OF_ALL_DTBS
kbuild: Allow .dtso format for overlay source files
of: unit
On 05-03-21, 15:00, Jie Deng wrote:
> On 2021/3/5 11:09, Viresh Kumar wrote:
> > On 05-03-21, 09:46, Jie Deng wrote:
> > > On 2021/3/4 14:06, Viresh Kumar wrote:
> > > > > + mutex_lock(>i2c_lock);
> > > > I have never worked with i2c stuff ear
On 04-03-21, 15:07, Beata Michalska wrote:
> The current_opp when set, grabs additional reference on the opp,
> which is then supposed to be dropped upon releasing the opp table.
> Still both dev_pm_opp_remove_table and dev_pm_opp_remove_all_dynamic
> will completely drain the OPPs list, including
On 05-03-21, 09:46, Jie Deng wrote:
> On 2021/3/4 14:06, Viresh Kumar wrote:
> > depends on I2C as well ?
> No need that. The dependency of I2C is included in the Kconfig in its parent
> directory.
Sorry about that, I must have figured that out myself.
(Though a note on t
On 04-03-21, 09:59, Jie Deng wrote:
> Add an I2C bus driver for virtio para-virtualization.
>
> The controller can be emulated by the backend driver in
> any device model software by following the virtio protocol.
>
> The device specification can be found on
>
On 03-03-21, 11:49, Geert Uytterhoeven wrote:
> Hi Viresh,
>
> On Wed, Mar 3, 2021 at 5:36 AM Viresh Kumar wrote:
> > From: Rob Herring
> >
> > Add a generic rule to apply fdtoverlay in Makefile.lib, so every
> > platform doesn't need to carry the complex rule
On 03-03-21, 11:44, Geert Uytterhoeven wrote:
> Hi Viresh,
>
> On Wed, Mar 3, 2021 at 6:21 AM Viresh Kumar wrote:
> > On 24-02-21, 19:32, Frank Rowand wrote:
> > > I overlooked this and mistakenly thought that the move to .dtbo also
> > > involved changing
On 03-03-21, 16:46, Jie Deng wrote:
> This is not a problem. My original proposal was to mirror the struct
> i2c_msg.
> The code you looked at was based on that.
> However, the virtio TC prefer not to mirror it. They have some concerns.
> For example, there is a bit I2C_M_RD in i2c_msg.flag which
On 01-03-21, 14:41, Jie Deng wrote:
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> +static int virtio_i2c_send_reqs(struct virtqueue *vq,
> + struct virtio_i2c_req *reqs,
> + struct i2c_msg *msgs, int nr)
>
On 24-02-21, 19:32, Frank Rowand wrote:
> I overlooked this and mistakenly thought that the move to .dtbo also
> involved changing to .dtso. My bad.
>
> My favorite color here is to use .dtso for the source file that will
> be compiled to create a .dtbo.
>
> Linus has already accepted patch 4/6
checks
for. These overlays will cause fdtoverlay to fail, and are thus not
included for static builds.
Signed-off-by: Viresh Kumar
---
drivers/of/unittest-data/Makefile | 50 ++
drivers/of/unittest-data/static_base_1.dts | 4 ++
drivers/of/unittest-data/static_base_2
quot; node to
testcases.dts from tests-interrupts.dtsi, as this node has a deliberate
error in it and is only relevant for runtime testing done with
unittest.c.
Signed-off-by: Viresh Kumar
---
drivers/of/unittest-data/overlay_base.dts | 90 +-
drivers/of/unittest-data/overlay_common.
We update 'extra-y' based on CONFIG_OF_ALL_DTBS three times. It would be
far more straight forward if we rather update dtb-y to include all .dtb
files if CONFIG_OF_ALL_DTBS is enabled.
Signed-off-by: Viresh Kumar
---
scripts/Makefile.lib | 5 ++---
1 file changed, 2 insertions(+), 3 deletions
, already merged.
- Patch 1/3 is new, suggested by Rob and slightly modified by me.
- Adapt Patch 3/3 to the new rule and name the overlay dtbs as .dtbo.
--
Viresh
Rob Herring (1):
kbuild: Add generic rule to apply fdtoverlay
Viresh Kumar (3):
kbuild: Simplify builds with CONFIG_OF_ALL_DTBS
of:
don't want to run schema checks on foo.dtb (as foo.dts doesn't exist)
and the Makefile is updated accordingly.
Signed-off-by: Rob Herring
Co-developed-by: Viresh Kumar
Signed-off-by: Viresh Kumar
---
scripts/Makefile.lib | 24 ++--
1 file changed, 22 insertions(+), 2
On 02-03-21, 16:40, Dmitry Osipenko wrote:
> 20.01.2021 19:01, Dmitry Osipenko пишет:
> > 01.01.2021 19:54, Yangtao Li пишет:
> >> Hi,
> >>
> >> This patchset add devm_pm_opp_set_clkname, devm_pm_opp_put_clkname,
> >> devm_pm_opp_set_regulators, devm_pm_opp_put_regulators,
> >>
On 02-03-21, 14:24, Jie Deng wrote:
> Not for the full duplex. As Paolo explained in those links.
> We defined a combined request called "write-read request"
>
> "
> This is when a write is followed by a read: the master
> starts off the transmission with a write, then sends a second START,
>
On 02-03-21, 13:21, Jie Deng wrote:
>
> On 2021/3/2 12:42, Viresh Kumar wrote:
> > On 01-03-21, 14:41, Jie Deng wrote:
> > > +static int virtio_i2c_send_reqs(struct virtqueue *vq,
> > > + struct virtio_i2c_req *reqs,
> > > +
On 02-03-21, 13:06, Jie Deng wrote:
> Yeah. Actually, the backend only needs "struct virtio_i2c_out_hdr out_hdr"
> and "struct virtio_i2c_in_hdr in_hdr" for communication. So we only need to
> keep
> the first two in uapi and move "struct virtio_i2c_req" into the driver.
>
> But Jason wanted to
On 01-03-21, 14:41, Jie Deng wrote:
> +static int virtio_i2c_send_reqs(struct virtqueue *vq,
> + struct virtio_i2c_req *reqs,
> + struct i2c_msg *msgs, int nr)
> +{
> + struct scatterlist *sgs[3], out_hdr, msg_buf, in_hdr;
> + int i,
On 02-03-21, 09:31, Viresh Kumar wrote:
> On 01-03-21, 16:19, Arnd Bergmann wrote:
> > On Mon, Mar 1, 2021 at 7:41 AM Jie Deng wrote:
> >
> > > --- /dev/null
> > > +++ b/include/uapi/linux/virtio_i2c.h
> > > @@ -0,0 +1,56 @@
> > > +/* SPDX-Lice
On 01-03-21, 16:19, Arnd Bergmann wrote:
> On Mon, Mar 1, 2021 at 7:41 AM Jie Deng wrote:
>
> > --- /dev/null
> > +++ b/include/uapi/linux/virtio_i2c.h
> > @@ -0,0 +1,56 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later WITH Linux-syscall-note */
> > +/*
> > + * Definitions for virtio I2C
On 01-03-21, 21:14, Frank Rowand wrote:
> Hi Viresh,
>
> On 3/1/21 12:56 AM, Viresh Kumar wrote:
> > On 12-02-21, 16:48, Viresh Kumar wrote:
> >> Hi,
> >>
> >> This patchset adds a generic rule for applying overlays using fdtoverlay
> >> tool
and so left it
for the right people to handle. :)
Acked-by: Viresh Kumar
--
viresh
On 01-03-21, 16:46, Arnd Bergmann wrote:
> But the driver does not support this at all: the sglist always has three
> members as Viresh says: outhdr, msgbuf and inhdr. It then uses a
> bounce buffer for the actual data transfer, and this always goes either
> one way or the other.
Yes and if the
On 01-03-21, 14:10, Andy Shevchenko wrote:
> On Mon, Mar 01, 2021 at 02:09:25PM +0200, Andy Shevchenko wrote:
> > On Mon, Mar 01, 2021 at 05:24:41PM +0530, Viresh Kumar wrote:
> > > On 01-03-21, 14:41, Jie Deng wrote:
> > > > +/**
> > > > + * stru
On 02-03-21, 10:21, Jie Deng wrote:
> On 2021/3/1 19:54, Viresh Kumar wrote:
> That's my original proposal. I used to mirror this interface with "struct
> i2c_msg".
>
> But the design philosophy of virtio TC is that VIRTIO devices are not
> specific to Linux
> s
On 01-03-21, 14:41, Jie Deng wrote:
> +/**
> + * struct virtio_i2c_req - the virtio I2C request structure
> + * @out_hdr: the OUT header of the virtio I2C message
> + * @write_buf: contains one I2C segment being written to the device
> + * @read_buf: contains one I2C segment being read from the
On 12-02-21, 16:48, Viresh Kumar wrote:
> Hi,
>
> This patchset adds a generic rule for applying overlays using fdtoverlay
> tool and then updates unittests to get built statically using the same.
>
> V7->V8:
> - Patch 1 is new.
> - Platforms need to use dtb-y += f
to show that cpufreq is also acts as source of
information for FIE and will be used by default if no other counters are
supported for a platform.
Reviewed-by: Ionela Voinescu
Tested-by: Ionela Voinescu
Signed-off-by: Viresh Kumar
---
arch/arm64/include/asm/topology.h | 10 +--
arch/arm64/kernel
invariance support if they want,
this is all done under CONFIG_ACPI_CPPC_CPUFREQ_FIE, which is enabled by
default.
This also exports sched_setattr_nocheck() as the CPPC driver can be
built as a module.
Cc: Ionela Voinescu
Cc: linux-a...@vger.kernel.org
Signed-off-by: Viresh Kumar
---
drivers
the callbacks is improved, so different
parts looking to provide their callbacks don't need to think about
each other.
- Moved to per-cpu storage for storing the callback related data, AMU
counters have higher priority with this.
--
viresh
Viresh Kumar (2):
topology: Allow multiple entities
On 28-02-21, 09:33, Shawn Guo wrote:
> Commit 67fc209b527d ("cpufreq: qcom-hw: drop devm_xxx() calls from
> init/exit hooks") introduces an issue of dereferencing freed memory
> 'data'. Fix it.
>
> Fixes: 67fc209b527d ("cpufreq: qcom-hw: drop devm_xxx() calls from init/exit
> hooks")
>
On 28-02-21, 02:11, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 3fb6d0e00efc958d01c2f109c8453033a2d96796
> commit: 406e47652161d4f0d9bc4cd6237b36c51497ec75 opp: Create
> _of_add_table_indexed() to reduce code
On 26-02-21, 10:46, Jie Deng wrote:
> This v4 was the old version before the specification was acked by the virtio
> tc.
>
> Following is the latest specification.
>
> https://raw.githubusercontent.com/oasis-tcs/virtio-spec/master/virtio-i2c.tex
>
> I will send the v5 since the host/guest ABI
On 12-10-20, 09:55, Jie Deng wrote:
> Add an I2C bus driver for virtio para-virtualization.
>
> The controller can be emulated by the backend driver in
> any device model software by following the virtio protocol.
>
> This driver communicates with the backend driver through a
> virtio I2C
On 22-02-21, 16:57, Rafael J. Wysocki wrote:
> On Mon, Feb 22, 2021 at 12:20 PM Viresh Kumar wrote:
> Even though the driver is located in drivers/cpufreq/ CPPC is part of
> ACPI and so a CC to linux-acpi is missing.
I just used get-maintainers, perhaps we should add
-
> 1 file changed, 12 insertions(+), 17 deletions(-)
Acked-by: Viresh Kumar
--
viresh
On 24-02-21, 13:42, Yue Hu wrote:
> From: Yue Hu
>
> Note that sugov_update_next_freq() may return false, that means the
> caller sugov_fast_switch() will do nothing except fast switch check.
>
> Similarly, sugov_deferred_update() also has unnecessary operations
> of raw_spin_{lock,unlock} in
ripts: dtc: Build fdtoverlay tool")
> Reported-by: Linus Torvalds
> Cc: Viresh Kumar
> Signed-off-by: Rob Herring
> ---
> Linus, please pick this up directly if you want. I'm going to be offline
> most of the next couple of days, will have a few other DT fixes to send
> you
is enabled by
default.
This also exports sched_setattr_nocheck() as the CPPC driver can be
built as a module.
Cc: Ionela Voinescu
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/Kconfig.arm| 9 ++
drivers/cpufreq/cppc_cpufreq.c | 223 +++--
include/linux
to show that cpufreq is also acts as source of
information for FIE and will be used by default if no other counters are
supported for a platform.
Reviewed-by: Ionela Voinescu
Tested-by: Ionela Voinescu
Signed-off-by: Viresh Kumar
---
arch/arm64/include/asm/topology.h | 10 +--
arch/arm64/kernel
the callback related data, AMU
counters have higher priority with this.
--
viresh
Viresh Kumar (2):
topology: Allow multiple entities to provide sched_freq_tick()
callback
cpufreq: cppc: Add support for frequency invariance
arch/arm64/include/asm/topology.h | 10 +-
arch/arm64/kernel
On 22-02-21, 11:00, Ionela Voinescu wrote:
> Hey,
>
> Some test results:
Nice, I haven't responded earlier as Vincent was also testing the
stuff out later last week and was planning to do it more this week.
> On Thursday 18 Feb 2021 at 16:35:38 (+), Ionela Voinescu wrote:
> [..]
> > >
Signed-off-by: Viresh Kumar
---
drivers/mailbox/arm_mhuv2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mailbox/arm_mhuv2.c b/drivers/mailbox/arm_mhuv2.c
index cdfb1939fabf..d997f8ebfa98 100644
--- a/drivers/mailbox/arm_mhuv2.c
+++ b/drivers/mailbox/arm_mhuv2.c
On 19-02-21, 19:45, Yue Hu wrote:
> We will set next_f to next_freq(previous freq) if next_f is
> reduced for busy CPU. Then the next sugov_update_next_freq() will check
> if next_freq matches next_f if need_freq_update is not set.
> Obviously, we will do nothing for the case. And The related
On 19-02-21, 19:16, Sudeep Holla wrote:
> Hi Viresh,
>
> On Fri, Feb 19, 2021 at 09:49:44AM +0530, Viresh Kumar wrote:
> > On 18-02-21, 22:23, Nicola Mazzucato wrote:
> > > Hi Viresh,
> > >
> > > In this V8 I have addressed your comments:
> > &
On 19-02-21, 09:44, Ionela Voinescu wrote:
> On Friday 19 Feb 2021 at 10:28:23 (+0530), Viresh Kumar wrote:
> > The very core routines (cpufreq_freq_transition_end() and
> > cpufreq_driver_fast_switch()) of the cpufreq core call
> > arch_set_freq_scale() today and this
On 19-02-21, 16:20, Yue Hu wrote:
> However, we will skip the update if need_freq_update is not set.
Not really, we will update freq periodically nevertheless, around
every 10ms or something..
> And do the update if need_freq_update is set.
Yeah, that breaks the periodic cycle to attend to some
On 19-02-21, 14:41, Yue Hu wrote:
> On Fri, 19 Feb 2021 09:39:33 +0530
> Viresh Kumar wrote:
>
> > On 19-02-21, 11:38, Yue Hu wrote:
> > > There's a possibility: we will use the previous freq to update if
> > > next_f is reduced for bu
On 18-02-21, 23:20, Frank Rowand wrote:
> Hi Viresh,
>
> I am in the wrong version with the comments below. You are at version 8 now.
Yeah, it is fine. I have updated the patches already based on your
comments.
--
viresh
On 18-02-21, 16:36, Ionela Voinescu wrote:
> Yes, we don't care if there is no cpufreq driver, as the use of AMUs won't
> get initialised either. But we do care if there is a cpufreq driver that
> does not support frequency invariance, which is the example above.
>
> The intention with the
On 18-02-21, 22:23, Nicola Mazzucato wrote:
> Hi Viresh,
>
> In this V8 I have addressed your comments:
> - correct the goto in patch 1/3
> - improve comment in patch 2/3 for dev_pm_opp_get_opp_count()
LGTM. I will apply them after the merge window is over. Thanks.
--
viresh
On 19-02-21, 11:38, Yue Hu wrote:
> There's a possibility: we will use the previous freq to update if next_f
> is reduced for busy CPU if need_freq_update is set in
> sugov_update_next_freq().
Right.
> This possibility would happen now? And this
> update is what we want if it happens?
This is
On 18-02-21, 18:14, Vinod Koul wrote:
> On 17-02-21, 10:19, Viresh Kumar wrote:
> > On 16-02-21, 16:42, Vinod Koul wrote:
> > > Add the CPUfreq compatible for SM8350 SoC along with note for using the
> > > specific compatible for SoCs
> > &
On 18-02-21, 10:03, Thara Gopinath wrote:
> Scheduling a notifier for max frequency change from the qos framework should
> do the work, right?
Not that, but we need to increase/decrease cooling states at run time,
create sysfs files/directories, etc. It isn't worth it.
--
viresh
On 15-02-21, 07:51, Nicola Mazzucato wrote:
> The current implementation of the scmi_cpufreq_init() function returns
> -EPROBE_DEFER when the OPP table is not populated. In practice the
> cpufreq core cannot handle this error code.
> Therefore, fix the return value and clarify the error message.
>
On 15-02-21, 07:51, Nicola Mazzucato wrote:
> + /*
> + * Add OPPs only on those CPUs for which we haven't already done so.
> + */
> nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
Please add a more detailed comment here explaining why you expect OPPs
to be present here in advance.
On 18-02-21, 16:25, Yue Hu wrote:
> From: Yue Hu
>
> For busy CPU case, we do not need to avoid freq reduction if limits
> change since commit 600f5badb78c ("cpufreq: schedutil: Don't skip
> freq update when limits change").
>
> Later, commit 23a881852f3e ("cpufreq: schedutil: Don't skip freq
>
On 17-02-21, 00:24, Ionela Voinescu wrote:
> > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> > index 1e47dfd465f8..47fca7376c93 100644
> > --- a/arch/arm64/kernel/topology.c
> > +++ b/arch/arm64/kernel/topology.c
> > @@ -240,7 +240,6 @@ static struct scale_freq_data
On 17-02-21, 10:32, Thara Gopinath wrote:
> First of all, I am still unable to find this setting in the sysfs space.
The driver needs to call cpufreq_enable_boost_support() for that.
> Irrespective the ideal behavior here will be to change the cpufreq cooling
> dev max state when this happens.
On 17-02-21, 11:57, Ionela Voinescu wrote:
> See a very useful comment someone added recently :) :
>
> """
> + /*
> + * We don't need to handle CPUFREQ_REMOVE_POLICY event as the AMU
> + * counters don't have any dependency on cpufreq driver once we have
> + * initialized AMU
nathan Marek
[ Viresh: Improved commit log and subject, rename current_freq as
current_rate, document it, remove local variable and rearrange
code. ]
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 8 +---
drivers/opp/opp.h | 2 ++
2 files changed, 7 insertions(+), 3 deletions
> Lukasz
>
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f32ebcff37d2..fe34f56acb0f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17774,7 +17774,7 @@ THERMAL/CPU_COOLING
> M: Amit Dan
On 17-02-21, 11:30, Ionela Voinescu wrote:
> The problem is not topology_scale_freq_invariant() but whether a scale
> factor is set for some CPUs.
>
> Scenario (test system above):
> - "AMUs" are only supported for [1-2],
> - cpufreq_supports_freq_invariance() -> false
>
> What should happen:
On 17-02-21, 10:29, Lukasz Luba wrote:
> On 2/17/21 5:48 AM, Viresh Kumar wrote:
> > freq_qos_update_request() returns 1 if the effective constraint value
> > has changed, 0 if the effective constraint value has not changed, or a
> > negative error code on failures.
&
Hi Thara,
On 16-02-21, 19:00, Thara Gopinath wrote:
> This is a fix for a regression observed on db845 platforms with 5.7-rc11
> kernel. On these platforms running stress tests with 5.11-rc7 kernel
> causes big cpus to overheat and ultimately shutdown the system due to
> hitting critical
l/cpu-cooling: Update thermal pressure in case of a
maximum frequency capping")
Signed-off-by: Viresh Kumar
---
Hi Guys,
This needs to go in 5.12-rc.
Thara, please give this a try and give your tested-by :).
drivers/thermal/cpufreq_cooling.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
On 16-02-21, 15:10, Jonathan Marek wrote:
> There is not "nothing to do" when the opp is the same. The frequency can
> be different from opp->rate.
I am sorry but I am not sure what are you trying to fix here and what exactly is
broken here. Can you provide a usecase for your platform where this
On 16-02-21, 16:42, Vinod Koul wrote:
> Add the CPUfreq compatible for SM8350 SoC along with note for using the
> specific compatible for SoCs
>
> Signed-off-by: Vinod Koul
> ---
> Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1
On 17-02-21, 00:24, Ionela Voinescu wrote:
> I think it could be merged in patch 1/2 as it's part of enabling the use
> of multiple sources of information for FIE. Up to you!
Sure.
> > static void amu_fie_setup(const struct cpumask *cpus)
> > {
> > - bool invariant;
> > int cpu;
> >
>
On 09-02-21, 15:40, Viresh Kumar wrote:
> And after decent amount of effort understanding how to do this, I
> finally did it in a not so efficient way, I am sure you can help
> improving it :)
Ping!
Also, where do we send patches for dt-schema ? Which list ?
> Author: Viresh K
On 14-02-21, 11:44, Yue Hu wrote:
> On Fri, 12 Feb 2021 17:14:03 +0100
> "Rafael J. Wysocki" wrote:
> > This may be running in parallel with sugov_update_next_freq() on a
> > different CPU, so the latter may clear need_freq_update right after it
> > has been set here unless I'm overlooking
es support.
--------
Viresh Kumar (18):
arch: alpha: Remove CONFIG_OPROFILE support
arch: arm: Remove CONFIG_OPROFILE support
arch: arc: Remove CONFIG_OPROFILE support
arch: hexagon: Don't select HAVE_OPROFILE
arch: ia64: Remove CONFI
quot; node to
testcases.dts from tests-interrupts.dtsi, as this node has a deliberate
error in it and is only relevant for runtime testing done with
unittest.c.
Signed-off-by: Viresh Kumar
---
drivers/of/unittest-data/overlay_base.dts | 90 +-
drivers/of/unittest-data/overlay_common.
checks
for. These overlays will cause fdtoverlay to fail, and are thus not
included for static builds.
Signed-off-by: Viresh Kumar
---
drivers/of/unittest-data/Makefile | 50 ++
drivers/of/unittest-data/static_base_1.dts | 4 ++
drivers/of/unittest-data/static_base_2
don't want to run schema checks on foo.dtb (as foo.dts doesn't exist)
and the Makefile is updated accordingly.
Signed-off-by: Rob Herring
Co-developed-by: Viresh Kumar
Signed-off-by: Viresh Kumar
---
scripts/Makefile.lib | 24 ++--
1 file changed, 22 insertions(+), 2
by me.
- Adapt Patch 3/3 to the new rule and name the overlay dtbs as .dtbo.
--
Viresh
Rob Herring (1):
kbuild: Add generic rule to apply fdtoverlay
Viresh Kumar (3):
kbuild: Simplify builds with CONFIG_OF_ALL_DTBS
of: unittest: Create overlay_common.dtsi and testcases_common.dtsi
of: un
We update 'extra-y' based on CONFIG_OF_ALL_DTBS three times. It would be
far more straight forward if we rather update dtb-y to include all .dtb
files if CONFIG_OF_ALL_DTBS is enabled.
Signed-off-by: Viresh Kumar
---
scripts/Makefile.lib | 5 ++---
1 file changed, 2 insertions(+), 3 deletions
On 12-02-21, 10:52, Johan Hovold wrote:
> But what will the checkpatch crew then work on?
Lol..
> Better staging than the rest of the kernel.
[ /me wondering on who stops them from sending patches for rest of the
kernel ? ]
--
viresh
On 12-02-21, 10:17, Greg KH wrote:
> On Fri, Feb 12, 2021 at 02:39:26PM +0530, Viresh Kumar wrote:
> > On 12-02-21, 13:48, Pritthijit Nath wrote:
> > > This change fixes a checkpatch CHECK style issue for "Alignment should
> > > match
> > > o
On 12-02-21, 13:48, Pritthijit Nath wrote:
> This change fixes a checkpatch CHECK style issue for "Alignment should match
> open parenthesis".
>
> Signed-off-by: Pritthijit Nath
> ---
> drivers/staging/greybus/hid.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On 12-02-21, 09:54, Greg KH wrote:
> On Fri, Feb 12, 2021 at 09:44:04AM +0100, Johan Hovold wrote:
> > On Fri, Feb 12, 2021 at 01:48:35PM +0530, Pritthijit Nath wrote:
> > > Fixed the spelling of 'transfered' to 'transferred'.
> > >
> > > Signed-off-by: Pritthijit Nath
> > > ---
> > >
On 12-02-21, 12:07, Masahiro Yamada wrote:
> BTW, I do not know how to use overlay.
> Do we apply overlay in the build time?
Ideally it can be applied at both build time and runtime, but we
haven't allowed the runtime way until now in kernel. This patchset is
all about applying it at build time.
freq/sfi-cpufreq.c | 127 --
> 3 files changed, 138 deletions(-)
> delete mode 100644 drivers/cpufreq/sfi-cpufreq.c
Acked-by: Viresh Kumar
--
viresh
On 11-02-21, 11:00, Greg KH wrote:
> On Thu, Feb 11, 2021 at 03:24:44PM +0530, Hemansh Agnihotri wrote:
> > This patch add fixes an checkpatch error for "Macros with multiple
> > statements
> > should be enclosed in a do - while loop"
> >
> > Signed-off-by: Hemansh Agnihotri
>
> Any reason you
checks
for. These overlays will cause fdtoverlay to fail, and are thus not
included for static builds.
Signed-off-by: Viresh Kumar
---
drivers/of/unittest-data/Makefile | 50 ++
drivers/of/unittest-data/static_base_1.dts | 4 ++
drivers/of/unittest-data/static_base_2
quot; node to
testcases.dts from tests-interrupts.dtsi, as this node has a deliberate
error in it and is only relevant for runtime testing done with
unittest.c.
Signed-off-by: Viresh Kumar
---
drivers/of/unittest-data/overlay_base.dts | 90 +-
drivers/of/unittest-data/overlay_common.
.
Signed-off-by: Rob Herring
[ Viresh: Add commit log and replace dtb-y with overlay-y, handle
CONFIG_OF_ALL_DTBS case, rearrange Makefile, don't add
overlay-y to dtb-y to skip dtbs_check for them. ]
Signed-off-by: Viresh Kumar
---
scripts/Makefile.lib | 39
tly modified by me.
- Adapt Patch 3/3 to the new rule and name the overlay dtbs as .dtbo.
--
Viresh
Rob Herring (1):
kbuild: Add generic rule to apply fdtoverlay
Viresh Kumar (2):
of: unittest: Create overlay_common.dtsi and testcases_common.dtsi
of: unittest: Statically apply overlays us
On 10-02-21, 00:25, Jassi Brar wrote:
> Yup any bug fix should be sent in rc. But this, imo, lies on the
> boundary of code and cosmetic issues, so I practiced discretion to
> keep it for the next pull request lest I won't have much to send ;)
Fair enough, would have been better though if you
On 20-01-21, 13:05, Bjorn Andersson wrote:
> On Wed 20 Jan 12:25 CST 2021, Taniya Das wrote:
>
> > The CPUFREQ-HW driver is intended to be used only for CPUFREQ HW designs
> > where the firmware programs the look up tables.
> >
>
> It's obvious that this is the intended target for the current
.c:1027:22: warning: dereference of noderef expression
drivers/mailbox/arm_mhuv2.c:1048:17: warning: dereference of noderef expression
Reported-by: kernel test robot
Signed-off-by: Viresh Kumar
---
Hi,
This should have been merged to 5.11-rc since the driver got introduced
in 5.11-rc1 itself. I
y skip this update.
>
> Hence, let's remove it to avoid above issue and make code more simple.
>
> Signed-off-by: Yue Hu
> ---
> kernel/sched/cpufreq_schedutil.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
Acked-by: Viresh Kumar
--
viresh
I am sure you can help
improving it :)
Author: Viresh Kumar
Date: Tue Feb 9 12:19:50 2021 +0530
dt-validate: Skip "required property" checks for overlays
The overlays may not carry the required properties and would depend on
the base dtb to carry those, there is no
On 08-02-21, 08:21, Rob Herring wrote:
> In string 'm' replace '.dtb' with '-dtbs'. Then we get the value of
> that variable.
Ah, thanks. I was able to get everything to work as expected now :)
> > ifneq ($(CHECK_DTBS),)
> > extra-y += $(patsubst %.dtb,%.dt.yaml, $(dtb-y))
> > +extra-y +=
On 03-02-21, 19:54, Rob Herring wrote:
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index b00855b247e0..886d2e6c58f0 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -66,6 +66,9 @@ multi-used := $(multi-used-y) $(multi-used-m)
> real-obj-y := $(foreach m,
101 - 200 of 16408 matches
Mail list logo
