On 29-05-25, 14:05, Jason Wang wrote:
> On Wed, May 21, 2025 at 7:34 PM Viresh Kumar wrote:
> >
> > The MMIO transport implementation creates a list of virtqueues for a
> > virtio device, while the same is already available in the struct
> > virtio_device.
> >
.
Remove the unwanted code to simplify the driver.
Signed-off-by: Viresh Kumar
---
Only build tested.
---
drivers/virtio/virtio_vdpa.c | 44 +++-
1 file changed, 3 insertions(+), 41 deletions(-)
diff --git a/drivers/virtio/virtio_vdpa.c b/drivers/virtio/virtio_vdpa.c
On 22-05-25, 14:07, Sapkal, Swapnil wrote:
> Initially I tried the same, but it does not work properly with the root user.
Hmm,
Tried chatgpt now and it says this should work:
if ! cat "$1/$file" 2>/dev/null; then
printf "$file is not readable\n"
fi
- This attempts to read the file.
- If it
like "&vm_dev->vdev" (which currently fails to build).
Signed-off-by: Viresh Kumar
---
I have tested this with a Xen/Qemu based setup to test guest to host virtio-i2c
communication. Works fine, not sure why this code was added in the first place.
drivers/vir
On 30-04-25, 17:14, Swapnil Sapkal wrote:
> In cpufreq basic selftests, one of the testcases is to read all cpufreq
> sysfs files and print the values. This testcase assumes all the cpufreq
> sysfs files have read permissions. However certain cpufreq sysfs files
> (eg. stats/reset) are write only f
On 17-12-24, 11:54, Ma Ke wrote:
> When device_add(&dev->dev) failed, calling put_device() to explicitly
> release dev->dev. Otherwise, it could cause double free problem.
>
> Found by code review.
>
> Cc: sta...@vger.kernel.org
> Fixes: 694a1116b405 ("virtio: Bind virtio device to device-tree no
ull.txt
> cpufreq/cpufreq_selftest.txt
>
> Cc: "Rafael J. Wysocki"
> Cc: Viresh Kumar
> Cc: Shuah Khan
> Signed-off-by: Li Zhijian
Acked-by: Viresh Kumar
--
viresh
atic u32 virtio_i2c_func(struct i2c_adapter *adap)
> }
>
> static struct i2c_algorithm virtio_algorithm = {
> - .master_xfer = virtio_i2c_xfer,
> + .xfer = virtio_i2c_xfer,
> .functionality = virtio_i2c_func,
> };
Acked-by: Viresh Kumar
--
viresh
On 28-12-23, 12:41, Ulf Hansson wrote:
> For OPP integration, as a follow up I am striving to make the
> dev_pm_opp_attach_genpd() redundant. Instead I think we should move towards
> using dev_pm_opp_set_config()->_opp_set_required_devs(), which would allow us
> to
> use the helpers that $subject
maximum freq_qos pressure on the capacity to the
> scheduler, which includes cpufreq cooling device. Remove the call to
> arch_update_thermal_pressure() in cpufreq cooling device as this is
> handled by cpufreq_get_pressure().
>
> Signed-off-by: Vincent Guittot
> Reviewed-by: L
On 12-12-23, 15:27, Vincent Guittot wrote:
> @@ -2618,6 +2663,9 @@ static int cpufreq_set_policy(struct cpufreq_policy
> *policy,
> policy->max = __resolve_freq(policy, policy->max, CPUFREQ_RELATION_H);
> trace_cpu_frequency_limits(policy);
>
> + cpus = policy->related_cpus;
> +
On 13-12-23, 16:41, Tim Chen wrote:
> Seems like the pressure value computed from the first CPU applies to all CPU.
> Will this be valid for non-homogeneous CPUs that could have different
> max_freq and max_capacity?
The will be part of different cpufreq policies and so it will work
fine.
--
vir
On 12-12-23, 15:27, Vincent Guittot wrote:
> Provide to the scheduler a feedback about the temporary max available
> capacity. Unlike arch_update_thermal_pressure, this doesn't need to be
> filtered as the pressure will happen for dozens ms or more.
>
> Signed-off-by: Vincent Guittot
> ---
> dri
On 19-04-21, 13:52, Bjorn Andersson wrote:
> On Tue 19 Jan 11:45 CST 2021, AngeloGioacchino Del Regno wrote:
> @Viresh, do you have any suggestion regarding my last comment?
> > static int qcom_cpufreq_hw_driver_probe(struct platform_device *pdev)
> > {
> > + const struct qcom_cpufreq_soc_data
On 15-04-21, 09:28, Wolfram Sang wrote:
>
> > Now that we were able to catch you, I will use the opportunity to
> > clarify the doubts I had.
> >
> > - struct mutex lock in struct virtio_i2c, I don't think this is
> > required since the core takes care of locking in absence of this.
>
> This i
On 15-04-21, 09:21, Wolfram Sang wrote:
>
> > I didn't forget this. It is a very small change. I'm not sure if the
> > maintainer Wolfram
> >
> > has any comments so that I can address them together in one version.
>
> Noted. I'll have a look in the next days.
Now that we were able to catch you
On 15-04-21, 14:56, Jie Deng wrote:
>
> On 2021/4/15 14:45, Viresh Kumar wrote:
> > On 23-03-21, 10:27, Arnd Bergmann wrote:
> > > I usually recommend the use of __maybe_unused for the suspend/resume
> > > callbacks for drivers that use SIMPLE_DEV_PM_OPS() or simil
On 23-03-21, 10:27, Arnd Bergmann wrote:
> I usually recommend the use of __maybe_unused for the suspend/resume
> callbacks for drivers that use SIMPLE_DEV_PM_OPS() or similar helpers
> that hide the exact conditions under which the functions get called.
>
> In this driver, there is an explicit #i
On 14-04-21, 10:07, Jie Deng wrote:
> Hi maintainers,
>
> What's the status of this patch based on the review comments you got ?
I was expecting a new version to be honest..
> Is i2c/for-next the right tree to merge it
> ?
It should be.
--
viresh
On 12-04-21, 15:01, Taniya Das wrote:
> Technically the HW we are trying to program here differs in terms of
> clocking, the LUT definitions and many more. It will definitely make
> debugging much more troublesome if we try to accomodate multiple versions of
> CPUFREQ-HW in the same code.
>
> Thus
On 19-01-21, 18:45, AngeloGioacchino Del Regno wrote:
> **
> ** NOTE: To "view the full picture", please look at the following
> ** patch series:
> ** https://patchwork.kernel.org/project/linux-arm-msm/list/?series=413355
> ** This is a subset of that series.
> **
>
> Chan
On 09-04-21, 09:55, Chen Lifu wrote:
> commit 77f983a9df42 ("spi: pl022: Use GPIOs looked up by the core")
> deleted 'struct pl022_ssp_controller' member 'num_chipselect'.
> We get build error when CONFIG_ARCH_SPEAR3XX is set:
> arch/arm/mach-spear/spear3xx.c:42:3: error: 'struct pl022_ssp_controll
On Fri, Nov 6, 2020 at 2:59 AM Peter Hilber
wrote:
> +static int scmi_vio_probe(struct virtio_device *vdev)
> +{
> + struct device *dev = &vdev->dev;
> + struct scmi_vio_channel **vioch;
> + bool have_vq_rx;
> + int vq_cnt;
> + int i;
> + struct virtqueue *vqs[
On 31-03-21, 13:21, andrew-sh.cheng wrote:
> Hi Viresh,
> Yes.
> As you mentioned, it will be enable by OPP core.
>
> Per discuss with hotplug owner and regulator owner,
> they suggest that "users should not suppose other module, will enable
> regulators for them".
> They suggest to add enable_reg
On 23-03-21, 19:33, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng"
>
> Need to enable regulator,
> so that the max/min requested value will be recorded
> even it is not applied right away.
>
> Intermediate clock is not always enabled by ccf in different projects,
> so cpufreq should enable it
<&CPU_SLEEP_0>;
> - clocks = <&infracfg CLK_INFRA_CA57SEL>,
> + clocks = <&infracfg CLK_INFRA_CA72SEL>,
><&apmixedsys CLK_APMIXED_MAINPLL>;
> clock-names = "cpu", "intermediate";
> operating-points-v2 = <&cpu_opp_table_b>;
Acked-by: Viresh Kumar
--
viresh
On 25-03-21, 18:19, Jian Dong wrote:
> From: Jian Dong
>
> fixes coccicheck Error:
>
> drivers/staging/greybus/bootrom.c:301:41-45: ERROR:
> fw is NULL but dereferenced.
>
> if procedure goto label directly, ret will be nefative, so the fw is NULL
> and the if(condition) end with dereferen
On 25-03-21, 10:14, Stanimir Varbanov wrote:
> I guess you meant this thread.
>
> https://lore.kernel.org/lkml/20210314163408.22292-1-dig...@gmail.com/
I actually thought some other stuff is having the merge issues (as I
was expecting something to happen there) :)
Anyway, you did the right thing
On 25-03-21, 10:13, Stanimir Varbanov wrote:
> Hi,
>
> On 3/14/21 6:34 PM, Dmitry Osipenko wrote:
> > From: Yangtao Li
> >
> > Use resource-managed OPP API to simplify code.
> >
> > Signed-off-by: Yangtao Li
> > Signed-off-by: Dmitry Osipenko
> > ---
> > drivers/media/platform/qcom/venus/cor
ion dev_pm_opp_of_cpumask_add_table() may return -EPROBE_DEFER,
which needs to be propagated to the caller to try probing the driver
later on.
Signed-off-by: Quanyang Wang
[ Viresh: Massage changelog/subject, improve code. ]
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq-dt.c
On 25-03-21, 13:15, quanyang.wang wrote:
> Thank you for pointing it out. Do you mean that even if
> dev_pm_opp_of_cpumask_add_table returns
>
> an error, dev_pm_opp_get_opp_count may still return count > 0 because
> someone may call dev_pm_opp_add
>
> to add OPP to cpu succcessfully at somewher
On 25-03-21, 12:31, quanyang.w...@windriver.com wrote:
> From: Quanyang Wang
>
> The function dev_pm_opp_of_cpumask_add_table may return zero or an
> error. When it returns an error, this means that no OPP table is
> added for the cpumask because _dev_pm_opp_cpumask_remove_table is
> called to fr
The overlay source files are named with .dtso extension now, add a new
rule to generate .dt.yaml for them.
Reviewed-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Signed-off-by: Viresh Kumar
---
V4:
- Rebase over Frank's cleanup patch:
https://lore.kernel.org
On 24-03-21, 16:49, Stanimir Varbanov wrote:
> Thanks Stephen!
>
> On 3/23/21 2:27 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the opp tree got a conflict in:
> >
> > drivers/media/platform/qcom/venus/pm_helpers.c
> >
> > between commit:
> >
> > 08b1cf474b7f
ignWare AHB DMA controller. This
> @@ -18,6 +19,7 @@ config DW_DMAC
> config DW_DMAC_PCI
> tristate "Synopsys DesignWare AHB DMA PCI driver"
> depends on PCI
> + depends on HAS_IOMEM
> select DW_DMAC_CORE
> help
> Support the Synopsys DesignWare AHB DMA controller on the
Acked-by: Viresh Kumar
--
viresh
On 24-03-21, 14:41, Jie Deng wrote:
>
> On 2021/3/24 14:09, Viresh Kumar wrote:
> > On 24-03-21, 14:05, Jie Deng wrote:
> > Or, now that I think about it a bit more, another thing we can do here is
> > see if
> > virtqueue_get_buf() returns NULL, if it does
On 24-03-21, 14:05, Jie Deng wrote:
> For simplicity, the original patch sent only 1 message to vq each time . I
> changed the way to send
I missed those earlier discussions :)
> a batch of requests in one time in order to improve efficiency according to
> Jason' suggestion.
I agree.
> As we di
On 23-03-21, 22:19, Jie Deng wrote:
> +static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> int num)
> +{
> + struct virtio_i2c *vi = i2c_get_adapdata(adap);
> + struct virtqueue *vq = vi->vq;
> + struct virtio_i2c_req *reqs;
> + unsigned long time_left;
> +
On 24-03-21, 12:00, Jie Deng wrote:
>
> On 2021/3/24 11:52, Viresh Kumar wrote:
> > On 24-03-21, 08:53, Jie Deng wrote:
> > > On 2021/3/23 17:38, Viresh Kumar wrote:
> > > > On 23-03-21, 14:31, Viresh Kumar wrote:
> > > > > On 23-03-21
On 24-03-21, 09:17, Jie Deng wrote:
> I didn't see the "struct virtio_driver" has a member "struct dev_pm_ops *pm"
>
> It defines its own hooks (freeze and restore) though it includes "struct
> device_driver"
>
> which has a "struct dev_pm_ops *pm".
>
> I just follow other virtio drivers to dire
On 24-03-21, 08:53, Jie Deng wrote:
>
> On 2021/3/23 17:38, Viresh Kumar wrote:
> > On 23-03-21, 14:31, Viresh Kumar wrote:
> > > On 23-03-21, 22:19, Jie Deng wrote:
> > > > +static int virtio_i2c_xfer(struct i2c_adapter *adap, struc
On 23-03-21, 14:31, Viresh Kumar wrote:
> On 23-03-21, 22:19, Jie Deng wrote:
> > +static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> > int num)
> > +{
> > + struct virtio_i2c *vi = i2c_get_adapdata(adap);
> > + struct virtq
On 23-03-21, 22:19, Jie Deng wrote:
> +static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> int num)
> +{
> + struct virtio_i2c *vi = i2c_get_adapdata(adap);
> + struct virtqueue *vq = vi->vq;
> + struct virtio_i2c_req *reqs;
> + unsigned long time_left;
> +
On 23-03-21, 16:33, Jie Deng wrote:
> On 2021/3/23 15:27, Viresh Kumar wrote:
>
> > On 23-03-21, 22:19, Jie Deng wrote:
> > > +static int __maybe_unused virtio_i2c_freeze(struct virtio_device *vdev)
> > > +{
> > > + virtio_i2c_del_vqs(vdev);
> > >
On 23-03-21, 22:19, Jie Deng wrote:
> +static int __maybe_unused virtio_i2c_freeze(struct virtio_device *vdev)
> +{
> + virtio_i2c_del_vqs(vdev);
> + return 0;
> +}
> +
> +static int __maybe_unused virtio_i2c_restore(struct virtio_device *vdev)
> +{
> + return virtio_i2c_setup_vqs(vdev-
On 23-03-21, 15:23, kernel test robot wrote:
> Hi Viresh,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 84196390620ac0e5070ae36af84c137c6216a7dc
> commit: 406e47652161d4f0d9bc4cd6237b36c51497ec75 opp: C
On 22-03-21, 09:08, Daniel Lezcano wrote:
> On 22/03/2021 04:29, Viresh Kumar wrote:
> > On 19-03-21, 21:25, Daniel Lezcano wrote:
> >> When the function successfully finishes it logs an information about
> >> the registration of the cooling device and use its nam
On 22-03-21, 15:53, Jie Deng wrote:
> I think your optimization has problems...
>
>
> > bool err_found = timeout;
While at it, see if you want to rename this variable as well to something
smaller, like "failed". I didn't touch it as it is a matter of personal choice,
so leaving it to you..
On 22-03-21, 15:53, Jie Deng wrote:
> On 2021/3/22 14:41, Viresh Kumar wrote:
> I think your optimization has problems...
>
>
> > bool err_found = timeout;
> >
> > for (i = 0; i < nr; i++) {
> > /* Detach the ith request from the vq */
On 22-03-21, 21:35, Jie Deng wrote:
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> new file mode 100644
> index 000..316986e
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-virtio.c
> @@ -0,0 +1,286 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> +
On 19-03-21, 21:25, Daniel Lezcano wrote:
> When the function successfully finishes it logs an information about
> the registration of the cooling device and use its name to build the
> message. Unfortunately it was freed right before:
>
> drivers/thermal/cpuidle_cooling.c:218 __cpuidle_cooling_re
On 19-03-21, 17:20, Rafael J. Wysocki wrote:
> Sorry for the delay.
>
> Acked-by: Rafael J. Wysocki
Thanks.
> and I'm assuming that either you or the sched guys will take care of it.
Yeah, I have already queued this up.
--
viresh
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.
> >
> &g
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.
This will get called from CPU's online/offline path at worst, nothing more.
>
On 19-03-21, 14:29, Jie Deng wrote:
> I also see example drivers/i2c/busses/i2c-xiic.c. Some people might think
> this way is more clearer than
>
> updating each member in probe. Basically, I think it's just a matter of
> personal preference which doesn't
Memory used by one instance of struct i2c
On 16-03-21, 18:35, Jie Deng wrote:
> +++ 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)
> +{
> + struct scatterlist *sgs[3], ou
On 19-03-21, 13:31, Jie Deng wrote:
>
> On 2021/3/19 11:54, Viresh Kumar wrote:
> > On 18-03-21, 15:52, Arnd Bergmann wrote:
> > > Allowing multiple virtio-i2c controllers in one system, and multiple i2c
> > > devices attached to each controller is clearly someth
On 18-03-21, 15:52, Arnd Bergmann wrote:
> Allowing multiple virtio-i2c controllers in one system, and multiple i2c
> devices attached to each controller is clearly something that has to work.
Good.
> I don't actually see a limitation though. Viresh, what is the problem
> you see for having multi
On 18-03-21, 13:27, Dmitry Osipenko wrote:
> 14.03.2021 19:48, Dmitry Osipenko пишет:
> > Add common helper which initializes OPP table for Tegra SoC core devices.
> >
> > Tested-by: Peter Geis # Ouya T30
> > Tested-by: Paul Fertser # PAZ00 T20
> > Tested-by: Nicolas Chauvet # PAZ00 T20 and TK1
On 16-03-21, 18:35, Jie Deng wrote:
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> +struct virtio_i2c {
> + struct virtio_device *vdev;
> + struct completion completion;
> + struct i2c_adapter *adap;
> + struct mutex lock;
> + struct virtqueue
On 16-03-21, 18:35, Jie Deng wrote:
> +static struct i2c_adapter virtio_adapter = {
> + .owner = THIS_MODULE,
> + .name = "Virtio I2C Adapter",
> + .class = I2C_CLASS_DEPRECATED,
> + .algo = &virtio_algorithm,
> +};
> +
> +static int virtio_i2c_probe(struct virtio_device *vdev)
> +{
On 12-03-21, 13:41, Viresh Kumar wrote:
> > > > +static struct i2c_adapter virtio_adapter = {
> > > > + .owner = THIS_MODULE,
> > > > + .name = "Virtio I2C Adapter",
> > > > + .class = I2C_CLASS_DEPRECATED,
&
oeven
Tested-by: Geert Uytterhoeven
Signed-off-by: Viresh Kumar
---
This was made part of the bigger patchset earlier (most of it already
got merged) whose last version was V11, but this patch was only sent
twice earlier and so starting with Version 3.
Changes since V2:
- Add the dts -> dtbo
On 16-03-21, 00:36, Frank Rowand wrote:
> I should have looked at patch 3/5 more carefully instead of counting on
> Masahiro to check it out and simply build testing.
>
> Patch 3/5 does not seem correct. I'll look over all the makefile related
> changes that have been accepted (if any) and patch
On 16-03-21, 02:43, Masahiro Yamada wrote:
> On Mon, Mar 15, 2021 at 3:40 PM Viresh Kumar wrote:
> > On 14-03-21, 20:16, Frank Rowand wrote:
> > What about doing this then in unittest's Makefile instead (which I
> > already suggested earlier), that will make everything
On 16-03-21, 11:15, Stephen Rothwell wrote:
> Hi all,
>
> After merging the opp tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> In file included from include/linux/devfreq.h:15,
> from drivers/base/power/main.c:36:
> include/linux/pm_opp.h:34
On 14-03-21, 20:16, Frank Rowand wrote:
> On 3/12/21 11:11 PM, Frank Rowand wrote:
> > On 3/12/21 1:13 AM, Viresh Kumar wrote:
> >> On 12-03-21, 01:09, Frank Rowand wrote:
> >>> I suggested having the .dtso files include the .dts file because that is
> >>>
On 12-03-21, 19:50, Tom Saeger wrote:
> Simplify case when setting default in cppc_cpufreq_get_transition_delay_us.
>
> Signed-off-by: Tom Saeger
> ---
> drivers/cpufreq/cppc_cpufreq.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/cpufreq/cppc_
On 14-03-21, 19:33, Dmitry Osipenko wrote:
> This series adds resource-managed OPP API helpers and makes drivers
> to use them.
>
> Changelog:
>
> v3: - Dropped dev_pm_opp_register_notifier().
>
> - Changed return type of the devm helpers from opp_table pointer
> to errno.
>
> - C
+), 68 deletions(-)
This patch has some updates in linux-next, which I don't have. Please
get this merged with the drm tree over 5.13-rc1 later.
Acked-by: Viresh Kumar
--
viresh
argument of type 'long unsigned int',
> but argument 3 has type 's64' {aka 'long long int'} [-Wformat=]
>
> CC: "Rafael J. Wysocki"
> CC: Viresh Kumar
> CC: linux...@vger.kernel.org
> Signed-off-by: Sergei Trofimovich
> ---
> driver
On 13-03-21, 09:19, Bhaskar Chowdhury wrote:
>
> Trivial spelling fixes throughout the file.
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> Changes from V2:
> Incoporated the findings of Tom Saeger
>
> drivers/cpufreq/s5pv210-cpufreq.c | 12 ++--
> 1 file changed, 6 insertions(+), 6
On 12-03-21, 18:03, Daniel Lezcano wrote:
> Currently the naming of a cooling device is just a cooling technique
> followed by a number. When there are multiple cooling devices using
> the same technique, it is impossible to clearly identify the related
> device as this one is just a number.
>
> F
On 12-03-21, 15:51, Jie Deng wrote:
>
> On 2021/3/12 14:10, Viresh Kumar wrote:
> > I saw your email about wrong version being sent, I already wrote some
> > reviews. Sending them anyway for FWIW :)
> >
> > On 12-03-21, 21:33, Jie Deng wrote:
> > &
On 12-03-21, 01:09, Frank Rowand wrote:
> I suggested having the .dtso files include the .dts file because that is a
> relatively
> small and easy change to test. What would probably make more sense is the
> rename
> the existing overlay .dts files to be .dtso files and then for each overlay
>
I saw your email about wrong version being sent, I already wrote some
reviews. Sending them anyway for FWIW :)
On 12-03-21, 21:33, Jie Deng wrote:
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> new file mode 100644
> index 000..bbde8de
> --- /dev/null
> +++
On 11-03-21, 22:20, Dmitry Osipenko wrote:
> +struct opp_table *devm_pm_opp_set_clkname(struct device *dev, const char
> *name)
> +{
> + struct opp_table *opp_table;
> + int err;
> +
> + opp_table = dev_pm_opp_set_clkname(dev, name);
> + if (IS_ERR(opp_table))
> + retur
On 11-03-21, 22:20, Dmitry Osipenko wrote:
> From: Yangtao Li
>
> Add devres wrapper for dev_pm_opp_register_notifier() to simplify driver
> code.
>
> Signed-off-by: Yangtao Li
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/opp/core.c | 38 ++
> inclu
above becomes:
>
> cpufreq-cpu0
> cpufreq-cpu4
> etc ...
>
> Signed-off-by: Daniel Lezcano
> ---
> drivers/thermal/cpufreq_cooling.c | 28 +++-----
> 1 file changed, 7 insertions(+), 21 deletions(-)
For 1,3/3
Acked-by: Viresh Kumar
--
viresh
On 10-03-21, 10:53, Viresh Kumar wrote:
> It is possible now for other parts of the kernel to provide their own
> implementation of sched_freq_tick() and they can very well be modules
> themselves (like CPPC cpufreq driver, which is going to use these in a
> later commit).
On 10-03-21, 20:24, Masahiro Yamada wrote:
> Even without "-I dts",
>
>inform = guess_input_format(arg, "dts");
>
> seems to fall back to "dts" anyway,
> but I guess you wanted to make this explicit, correct?
> > +# Required for of unit-test files as they can't be renamed to .dtso
>
> If y
On 10-03-21, 11:05, 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.
>
> V10->V11:
> - Update patch 4/5 to fix checkpatch warning on spaces and
On 11-03-21, 17:27, Frank Rowand wrote:
> On 3/9/21 11:35 PM, Viresh Kumar wrote:
> > Viresh Kumar (4):
> > kbuild: Simplify builds with CONFIG_OF_ALL_DTBS
> > kbuild: Allow .dtso format for overlay source files
> > of: unittest: Create overlay_common.dtsi and tes
# v5.11+
Fixes: cf1fac943c63 ("opp: Reduce the size of critical section in
_opp_kref_release()")
Signed-off-by: Beata Michalska
[ Viresh: Almost rewrote entire patch, added new "removed" field,
rewrote commit log and added the correct Fixes tag. ]
Co-developed-by: V
On 11-03-21, 00:18, Masahiro Yamada wrote:
> On Wed, Mar 10, 2021 at 11:48 PM Viresh Kumar wrote:
> >
> > On 10-03-21, 20:29, Masahiro Yamada wrote:
> > > BTW, is the attached patch good for DTC?
> > >
> > > I do not know when '-O dtbo' is use
On 10-03-21, 23:03, Beata Michalska wrote:
> > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > index c2689386a906..150be4c28c99 100644
> > --- a/drivers/opp/core.c
> > +++ b/drivers/opp/core.c
> > @@ -1492,7 +1492,11 @@ static struct dev_pm_opp *_opp_get_next(struct
> > opp_table *opp_tab
On 10-03-21, 20:29, Masahiro Yamada wrote:
> BTW, is the attached patch good for DTC?
>
> I do not know when '-O dtbo' is useful,
> unless I am missing something.
It is useful if we are sending the -O option all the time (I have
already given more details to your patch) as outform will not be NUL
On 10-03-21, 20:24, Masahiro Yamada wrote:
> On Wed, Mar 10, 2021 at 2:35 PM Viresh Kumar wrote:
> > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > index bc045a54a34e..59e86f67f9e0 100644
> > --- a/scripts/Makefile.lib
> > +++ b/scripts/Makefile.lib
&g
tc-tmp)
> $< ; \
> - $(DTC) -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \
> + $(DTC) -o $@ -b 0 \
> $(addprefix -i,$(dir $<) $(DTC_INCLUDE)) $(DTC_FLAGS) \
> -d $(depfile).dtc.tmp $(dtc-tmp) ; \
> cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
LGTM.
Reviewed-by: Viresh Kumar
--
viresh
quot; field,
rewrote commit log and added the correct Fixes tag. ]
Co-developed-by: Viresh Kumar
Signed-off-by: Viresh Kumar
---
drivers/opp/core.c | 48 --
drivers/opp/opp.h | 2 ++
2 files changed, 27 insertions(+), 23 deletions(-)
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 | 48 ++
drivers/of/unittest-data/static_base_1.dts | 4 ++
drivers/of/unittest-data/static_base_2
. 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 +++
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
am learning a lot every day :)
V6->V7:
- Dropped the first 4 patches, 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 fdtover
evice2" 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/overl
dtbs := foo_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.
Acked-by: Masahiro Yamada
Signed-off-by: Rob Herring
Co-developed-by: Viresh Kumar
Signed-off-
by: Ionela Voinescu
Tested-by: Vincent Guittot
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/Kconfig.arm| 10 ++
drivers/cpufreq/cppc_cpufreq.c | 245 +++--
include/linux/arch_topology.h | 1 +
kernel/sched/core.c| 1 +
4 files changed, 245 inserti
etting 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 (4):
arch_topology: Renam
().
Reviewed-by: Ionela Voinescu
Tested-by: Ionela Voinescu
Tested-by: Vincent Guittot
Signed-off-by: Viresh Kumar
---
drivers/base/arch_topology.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index ebcd2ea3091f..995e52b9eca4
and it is added 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
Acked-by: Will Deacon # for arm64
Tested-by: Vincent Guittot
Signed-off-b
1 - 100 of 5062 matches
Mail list logo
