* Re: [meta-arm] building gcc-arm-none-eabi from source
From: Alexander Kanavin @ 2022-01-05 21:14 UTC (permalink / raw)
To: Richard Purdie; +Cc: meta-arm, Stefan Herbrechtsmeier
In-Reply-To: <283cdfc898038fee9465d4f24bd0113ec712dbb1.camel@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On Tue, 4 Jan 2022 at 10:24, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:
> It is true that you'd need a different target variant for the second
> option I
> mentioned.
>
> I did have something slightly similar with extensions to the gcc/binutils
> recipes for a cross AVR toolchain that runs on an arm target. I found some
> copies here, based on daisy which whilst old, gives the idea:
>
>
> https://git.yoctoproject.org/poky-contrib/commit/?h=rpurdie/daisy&id=f58f90257a5af3e6b6974090e62cad9d90d53ae5
>
> I definitely have something more recent locally too (pyro, can't remember
> if I
> made it to dunfell with that code), I can dig that out if it is
> interesting. I
> thought somewhere I had a BBCLASSEXTEND recipe which added multiple cross
> compiler arches on target but I can't find that one :/.
>
After poking at the vendor toolchain a bit, I don't think building that
from source is a great option either. Perhaps the best solution is to use
the mcextend class to do the needed tweaks directly inside the binutils/gcc
recipes (or as bbappends in meta-arm perhaps). Does that sound about right?
Alex
[-- Attachment #2: Type: text/html, Size: 1712 bytes --]
^ permalink raw reply
* Re: more eBPF instruction set documentation improvements
From: Alexei Starovoitov @ 2022-01-05 21:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jonathan Corbet, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, linux-doc, netdev, bpf
In-Reply-To: <20220103183556.41040-1-hch@lst.de>
On Mon, Jan 03, 2022 at 07:35:50PM +0100, Christoph Hellwig wrote:
> Hi all,
>
> this series adds further improves the eBPF instruction set documentation.
> Mostly it adds descriptions to the various tables as requested by
> Alexei, but there are a few other minor tidyups as well.
Applied, Thanks
^ permalink raw reply
* Re: [PATCH v2] drm/msm/dp: add support of tps4 (training pattern 4) for HBR3
From: Stephen Boyd @ 2022-01-05 21:13 UTC (permalink / raw)
To: Kuogee Hsieh, agross, airlied, bjorn.andersson, daniel,
dmitry.baryshkov, robdclark, sean, vkoul
Cc: quic_sbillaka, linux-arm-msm, quic_abhinavk, dri-devel,
linux-kernel, Kuogee Hsieh, aravindh, freedreno
In-Reply-To: <1640801745-16234-1-git-send-email-quic_khsieh@quicinc.com>
Quoting Kuogee Hsieh (2021-12-29 10:15:45)
> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h b/drivers/gpu/drm/msm/dp/dp_catalog.h
> index 6965afa..7dea101 100644
> --- a/drivers/gpu/drm/msm/dp/dp_catalog.h
> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
> @@ -94,7 +94,7 @@ void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog *dp_catalog, bool enable);
> void dp_catalog_ctrl_config_misc(struct dp_catalog *dp_catalog, u32 cc, u32 tb);
> void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32 rate,
> u32 stream_rate_khz, bool fixed_nvid);
> -int dp_catalog_ctrl_set_pattern(struct dp_catalog *dp_catalog, u32 pattern);
> +int dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog *dp_catalog, u32 pattern);
> void dp_catalog_ctrl_reset(struct dp_catalog *dp_catalog);
> bool dp_catalog_ctrl_mainlink_ready(struct dp_catalog *dp_catalog);
> void dp_catalog_ctrl_enable_irq(struct dp_catalog *dp_catalog, bool enable);
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 39558a2..da6c083 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1078,12 +1078,13 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private *ctrl,
> int tries, old_v_level, ret = 0;
> u8 link_status[DP_LINK_STATUS_SIZE];
> int const maximum_retries = 4;
> + char state_ctrl_bit = 1;
>
> dp_catalog_ctrl_state_ctrl(ctrl->catalog, 0);
>
> *training_step = DP_TRAINING_1;
>
> - ret = dp_catalog_ctrl_set_pattern(ctrl->catalog, DP_TRAINING_PATTERN_1);
> + ret = dp_catalog_ctrl_set_pattern_state_bit(ctrl->catalog, state_ctrl_bit);
Why not inline 'state_ctrl_bit' value of 1 here?
> if (ret)
> return ret;
> dp_ctrl_train_pattern_set(ctrl, DP_TRAINING_PATTERN_1 |
> @@ -1181,7 +1182,7 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private *ctrl,
> int *training_step)
> {
> int tries = 0, ret = 0;
> - char pattern;
> + char pattern, state_ctrl_bit;
Why is 'state_ctrl_bit' a char when the function it's passed to takes a
u32? Please be consistent with types. It would be good to make 'pattern'
into a u8 as well instead of a char to be similarly consistent.
> int const maximum_retries = 5;
> u8 link_status[DP_LINK_STATUS_SIZE];
>
> @@ -1189,12 +1190,20 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private *ctrl,
>
> *training_step = DP_TRAINING_2;
>
> - if (drm_dp_tps3_supported(ctrl->panel->dpcd))
> + if (drm_dp_tps4_supported(ctrl->panel->dpcd)) {
> + pattern = DP_TRAINING_PATTERN_4;
> + state_ctrl_bit = 4;
> + }
> + else if (drm_dp_tps3_supported(ctrl->panel->dpcd)) {
> pattern = DP_TRAINING_PATTERN_3;
> - else
> + state_ctrl_bit = 3;
> + }
> + else {
> pattern = DP_TRAINING_PATTERN_2;
> + state_ctrl_bit = 2;
> + }
>
> - ret = dp_catalog_ctrl_set_pattern(ctrl->catalog, pattern);
> + ret = dp_catalog_ctrl_set_pattern_state_bit(ctrl->catalog, state_ctrl_bit);
> if (ret)
> return ret;
>
^ permalink raw reply
* Re: [PATCH v6 0/9] Multigenerational LRU Framework
From: Yu Zhao @ 2022-01-05 21:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Andi Kleen, Catalin Marinas, Dave Hansen,
Hillf Danton, Jens Axboe, Jesse Barnes, Johannes Weiner,
Jonathan Corbet, Matthew Wilcox, Mel Gorman, Michael Larabel,
Michal Hocko, Rik van Riel, Vlastimil Babka, Will Deacon,
Ying Huang, Linux ARM, open list:DOCUMENTATION,
Linux Kernel Mailing List, Linux-MM, page-reclaim,
the arch/x86 maintainers
In-Reply-To: <CAHk-=whMbX+GUBY=Fyxo3r-XVvfNyFA+4hUJS7UxgYDxf9Wbcw@mail.gmail.com>
On Tue, Jan 04, 2022 at 01:43:13PM -0800, Linus Torvalds wrote:
> On Tue, Jan 4, 2022 at 12:30 PM Yu Zhao <yuzhao@google.com> wrote:
> >
> > My goal is to get it merged asap so that users can reap the benefits
> > and I can push the sequels. Please examine the data provided -- I
> > think the unprecedented coverage and the magnitude of the improvements
> > warrant a green light.
>
> I'll leave this to Andrew. I had some stylistic nits, but all the
> actual complexity is in that aging and eviction, and while I looked at
> the patches, I certainly couldn't make much of a judgement on them.
>
> The proof is in the numbers, and they look fine, but who knows what
> happens when others test it. I don't see anything that looks worrisome
> per se, I just see the silly small things that made me go "Eww".
I appreciate your time, I'll address all your comments togather with
others' in the next spin, after I hear from Andrew. (I'm assuming he
will have comments too.)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] drm/msm/dp: add support of tps4 (training pattern 4) for HBR3
From: Stephen Boyd @ 2022-01-05 21:13 UTC (permalink / raw)
To: Kuogee Hsieh, agross, airlied, bjorn.andersson, daniel,
dmitry.baryshkov, robdclark, sean, vkoul
Cc: quic_abhinavk, aravindh, quic_sbillaka, freedreno, dri-devel,
linux-arm-msm, linux-kernel, Kuogee Hsieh
In-Reply-To: <1640801745-16234-1-git-send-email-quic_khsieh@quicinc.com>
Quoting Kuogee Hsieh (2021-12-29 10:15:45)
> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h b/drivers/gpu/drm/msm/dp/dp_catalog.h
> index 6965afa..7dea101 100644
> --- a/drivers/gpu/drm/msm/dp/dp_catalog.h
> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
> @@ -94,7 +94,7 @@ void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog *dp_catalog, bool enable);
> void dp_catalog_ctrl_config_misc(struct dp_catalog *dp_catalog, u32 cc, u32 tb);
> void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32 rate,
> u32 stream_rate_khz, bool fixed_nvid);
> -int dp_catalog_ctrl_set_pattern(struct dp_catalog *dp_catalog, u32 pattern);
> +int dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog *dp_catalog, u32 pattern);
> void dp_catalog_ctrl_reset(struct dp_catalog *dp_catalog);
> bool dp_catalog_ctrl_mainlink_ready(struct dp_catalog *dp_catalog);
> void dp_catalog_ctrl_enable_irq(struct dp_catalog *dp_catalog, bool enable);
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 39558a2..da6c083 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1078,12 +1078,13 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private *ctrl,
> int tries, old_v_level, ret = 0;
> u8 link_status[DP_LINK_STATUS_SIZE];
> int const maximum_retries = 4;
> + char state_ctrl_bit = 1;
>
> dp_catalog_ctrl_state_ctrl(ctrl->catalog, 0);
>
> *training_step = DP_TRAINING_1;
>
> - ret = dp_catalog_ctrl_set_pattern(ctrl->catalog, DP_TRAINING_PATTERN_1);
> + ret = dp_catalog_ctrl_set_pattern_state_bit(ctrl->catalog, state_ctrl_bit);
Why not inline 'state_ctrl_bit' value of 1 here?
> if (ret)
> return ret;
> dp_ctrl_train_pattern_set(ctrl, DP_TRAINING_PATTERN_1 |
> @@ -1181,7 +1182,7 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private *ctrl,
> int *training_step)
> {
> int tries = 0, ret = 0;
> - char pattern;
> + char pattern, state_ctrl_bit;
Why is 'state_ctrl_bit' a char when the function it's passed to takes a
u32? Please be consistent with types. It would be good to make 'pattern'
into a u8 as well instead of a char to be similarly consistent.
> int const maximum_retries = 5;
> u8 link_status[DP_LINK_STATUS_SIZE];
>
> @@ -1189,12 +1190,20 @@ static int dp_ctrl_link_train_2(struct dp_ctrl_private *ctrl,
>
> *training_step = DP_TRAINING_2;
>
> - if (drm_dp_tps3_supported(ctrl->panel->dpcd))
> + if (drm_dp_tps4_supported(ctrl->panel->dpcd)) {
> + pattern = DP_TRAINING_PATTERN_4;
> + state_ctrl_bit = 4;
> + }
> + else if (drm_dp_tps3_supported(ctrl->panel->dpcd)) {
> pattern = DP_TRAINING_PATTERN_3;
> - else
> + state_ctrl_bit = 3;
> + }
> + else {
> pattern = DP_TRAINING_PATTERN_2;
> + state_ctrl_bit = 2;
> + }
>
> - ret = dp_catalog_ctrl_set_pattern(ctrl->catalog, pattern);
> + ret = dp_catalog_ctrl_set_pattern_state_bit(ctrl->catalog, state_ctrl_bit);
> if (ret)
> return ret;
>
^ permalink raw reply
* [PATCH net] sch_cake: revise Diffserv docs
From: Kevin Bracey @ 2022-01-05 20:35 UTC (permalink / raw)
To: netdev; +Cc: toke, Kevin Bracey
Documentation incorrectly stated that CS1 is equivalent to LE for
diffserv8. But when LE was added to the table, CS1 was pushed into tin
1, leaving only LE in tin 0.
Also "TOS1" no longer exists, as that is the same codepoint as LE.
Make other tweaks properly distinguishing codepoints from classes and
putting current Diffserve codepoints ahead of legacy ones.
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
---
net/sched/sch_cake.c | 40 ++++++++++++++++++++--------------------
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
index 857aaebd49f4..64692414c0e5 100644
--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -2342,9 +2342,7 @@ static int cake_config_precedence(struct Qdisc *sch)
/* List of known Diffserv codepoints:
*
- * Least Effort (CS1, LE)
- * Best Effort (CS0)
- * Max Reliability & LLT "Lo" (TOS1)
+ * Default Forwarding (DF/CS0)
* Max Throughput (TOS2)
* Min Delay (TOS4)
* LLT "La" (TOS5)
@@ -2352,6 +2350,7 @@ static int cake_config_precedence(struct Qdisc *sch)
* Assured Forwarding 2 (AF2x) - x3
* Assured Forwarding 3 (AF3x) - x3
* Assured Forwarding 4 (AF4x) - x3
+ * Precedence Class 1 (CS1)
* Precedence Class 2 (CS2)
* Precedence Class 3 (CS3)
* Precedence Class 4 (CS4)
@@ -2360,8 +2359,9 @@ static int cake_config_precedence(struct Qdisc *sch)
* Precedence Class 7 (CS7)
* Voice Admit (VA)
* Expedited Forwarding (EF)
-
- * Total 25 codepoints.
+ * Lower Effort (LE)
+ *
+ * Total 26 codepoints.
*/
/* List of traffic classes in RFC 4594, updated by RFC 8622:
@@ -2375,12 +2375,12 @@ static int cake_config_precedence(struct Qdisc *sch)
* Realtime Interactive (CS4) - eg. games
* Multimedia Streaming (AF3x) - eg. YouTube, NetFlix, Twitch
* Broadcast Video (CS3)
- * Low Latency Data (AF2x,TOS4) - eg. database
- * Ops, Admin, Management (CS2,TOS1) - eg. ssh
- * Standard Service (CS0 & unrecognised codepoints)
- * High Throughput Data (AF1x,TOS2) - eg. web traffic
- * Low Priority Data (CS1,LE) - eg. BitTorrent
-
+ * Low-Latency Data (AF2x,TOS4) - eg. database
+ * Ops, Admin, Management (CS2) - eg. ssh
+ * Standard Service (DF & unrecognised codepoints)
+ * High-Throughput Data (AF1x,TOS2) - eg. web traffic
+ * Low-Priority Data (LE,CS1) - eg. BitTorrent
+ *
* Total 12 traffic classes.
*/
@@ -2390,12 +2390,12 @@ static int cake_config_diffserv8(struct Qdisc *sch)
*
* Network Control (CS6, CS7)
* Minimum Latency (EF, VA, CS5, CS4)
- * Interactive Shell (CS2, TOS1)
+ * Interactive Shell (CS2)
* Low Latency Transactions (AF2x, TOS4)
* Video Streaming (AF4x, AF3x, CS3)
- * Bog Standard (CS0 etc.)
- * High Throughput (AF1x, TOS2)
- * Background Traffic (CS1, LE)
+ * Bog Standard (DF etc.)
+ * High Throughput (AF1x, TOS2, CS1)
+ * Background Traffic (LE)
*
* Total 8 traffic classes.
*/
@@ -2437,9 +2437,9 @@ static int cake_config_diffserv4(struct Qdisc *sch)
/* Further pruned list of traffic classes for four-class system:
*
* Latency Sensitive (CS7, CS6, EF, VA, CS5, CS4)
- * Streaming Media (AF4x, AF3x, CS3, AF2x, TOS4, CS2, TOS1)
- * Best Effort (CS0, AF1x, TOS2, and those not specified)
- * Background Traffic (CS1, LE)
+ * Streaming Media (AF4x, AF3x, CS3, AF2x, TOS4, CS2)
+ * Best Effort (DF, AF1x, TOS2, and those not specified)
+ * Background Traffic (LE, CS1)
*
* Total 4 traffic classes.
*/
@@ -2477,9 +2477,9 @@ static int cake_config_diffserv4(struct Qdisc *sch)
static int cake_config_diffserv3(struct Qdisc *sch)
{
/* Simplified Diffserv structure with 3 tins.
- * Low Priority (CS1, LE)
+ * Low Priority (LE, CS1)
* Best Effort
- * Latency Sensitive (TOS4, VA, EF, CS6, CS7)
+ * Latency Sensitive (CS7, CS6, EF, VA, TOS4)
*/
struct cake_sched_data *q = qdisc_priv(sch);
u32 mtu = psched_mtu(qdisc_dev(sch));
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v6 0/9] Multigenerational LRU Framework
From: Yu Zhao @ 2022-01-05 21:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Andi Kleen, Catalin Marinas, Dave Hansen,
Hillf Danton, Jens Axboe, Jesse Barnes, Johannes Weiner,
Jonathan Corbet, Matthew Wilcox, Mel Gorman, Michael Larabel,
Michal Hocko, Rik van Riel, Vlastimil Babka, Will Deacon,
Ying Huang, Linux ARM, open list:DOCUMENTATION,
Linux Kernel Mailing List, Linux-MM, page-reclaim,
the arch/x86 maintainers
In-Reply-To: <CAHk-=whMbX+GUBY=Fyxo3r-XVvfNyFA+4hUJS7UxgYDxf9Wbcw@mail.gmail.com>
On Tue, Jan 04, 2022 at 01:43:13PM -0800, Linus Torvalds wrote:
> On Tue, Jan 4, 2022 at 12:30 PM Yu Zhao <yuzhao@google.com> wrote:
> >
> > My goal is to get it merged asap so that users can reap the benefits
> > and I can push the sequels. Please examine the data provided -- I
> > think the unprecedented coverage and the magnitude of the improvements
> > warrant a green light.
>
> I'll leave this to Andrew. I had some stylistic nits, but all the
> actual complexity is in that aging and eviction, and while I looked at
> the patches, I certainly couldn't make much of a judgement on them.
>
> The proof is in the numbers, and they look fine, but who knows what
> happens when others test it. I don't see anything that looks worrisome
> per se, I just see the silly small things that made me go "Eww".
I appreciate your time, I'll address all your comments togather with
others' in the next spin, after I hear from Andrew. (I'm assuming he
will have comments too.)
^ permalink raw reply
* Re: [PATCH 2/2] udoo: neo: Do not print the Model information
From: Tommaso Merciai @ 2022-01-05 21:10 UTC (permalink / raw)
To: Fabio Estevam; +Cc: Stefano Babic, U-Boot-Denx, Peter Robinson
In-Reply-To: <CAOMZO5CfCxnhqnE++q_TkMaQaw7DDdLnz+M9Q0Wkyt4uSEQ9sQ@mail.gmail.com>
On Wed, Jan 05, 2022 at 05:52:23PM -0300, Fabio Estevam wrote:
> Hi Tommaso,
>
> On Wed, Jan 5, 2022 at 5:47 PM Tommaso Merciai <tomm.merciai@gmail.com> wrote:
>
> > Hi Fabio,
> > Thanks, I test your patch on basic and extended model. Below some logs
> > seems all work properly. I hope I helped the cause :)
>
> Yes, thanks a lot!
>
> > - BASIC log:
> > -------------------------------------------------------------------------
> > U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 21:38:32 +0100)
> >
> > CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
> > CPU: Extended Commercial temperature grade (-20C to 105C) at 32C
> > Reset cause: POR
> > Model: UDOO Neo Basic
>
> I assume you have only applied 1/2 and not 2/2.
>
> With 2/2 applied the Model line should not be printed.
>
> Thanks
Yes, Fabio. Sorry, I forgot. Below test with 2/2.
U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 22:07:22 +0100)
CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 45C
Reset cause: POR
Board: UDOO Neo BASIC
I2C: ready
DRAM: 512 MiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC: FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@2188000
Hit any key to stop autoboot: 0
U-Boot 2022.01-rc4-00034-g19f31e718f-dirty (Jan 05 2022 - 22:07:22 +0100)
CPU: Freescale i.MX6SX rev1.2 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 35C
Reset cause: POR
Board: UDOO Neo EXTENDED
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC: FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net:
Error: ethernet@2188000 address not set.
No ethernet found.
Hit any key to stop autoboot: 0
Thanks,
Tommaso
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: sc7280: add sound card support
From: Stephen Boyd @ 2022-01-05 21:10 UTC (permalink / raw)
To: Srinivasa Rao Mandadapu, agross, bjorn.andersson, devicetree,
dianders, judyhsiao, linux-arm-msm, linux-kernel, robh+dt,
rohitkr, srinivas.kandagatla
Cc: Venkata Prasad Potturu
In-Reply-To: <1641208380-15510-4-git-send-email-quic_srivasam@quicinc.com>
Quoting Srinivasa Rao Mandadapu (2022-01-03 03:13:00)
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
> index 3449d56..63b1184 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
> @@ -637,6 +637,99 @@
> };
> };
>
> +&sound {
> + compatible = "google,sc7280-herobrine";
> + model = "sc7280-wcd938x-max98360a-1mic";
> + status = "okay";
> + audio-routing =
> + "IN1_HPHL", "HPHL_OUT",
> + "IN2_HPHR", "HPHR_OUT",
> + "AMIC1", "MIC BIAS1",
> + "AMIC2", "MIC BIAS2",
> + "VA DMIC0", "MIC BIAS3",
> + "VA DMIC1", "MIC BIAS3",
> + "VA DMIC2", "MIC BIAS1",
> + "VA DMIC3", "MIC BIAS1",
> + "TX SWR_ADC0", "ADC1_OUTPUT",
> + "TX SWR_ADC1", "ADC2_OUTPUT",
> + "TX SWR_ADC2", "ADC3_OUTPUT",
> + "TX SWR_DMIC0", "DMIC1_OUTPUT",
> + "TX SWR_DMIC1", "DMIC2_OUTPUT",
> + "TX SWR_DMIC2", "DMIC3_OUTPUT",
> + "TX SWR_DMIC3", "DMIC4_OUTPUT",
> + "TX SWR_DMIC4", "DMIC5_OUTPUT",
> + "TX SWR_DMIC5", "DMIC6_OUTPUT",
> + "TX SWR_DMIC6", "DMIC7_OUTPUT",
> + "TX SWR_DMIC7", "DMIC8_OUTPUT";
> +
> + qcom,msm-mbhc-hphl-swh = <1>;
> + qcom,msm-mbhc-gnd-swh = <1>;
Why are these last extra tabbed?
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #sound-dai-cells = <0>;
> +
> + dai-link@6 {
> + link-name = "WCD Playback";
> + reg = <LPASS_CDC_DMA_RX0>;
> + cpu {
> + sound-dai = <&lpass_cpu LPASS_CDC_DMA_RX0>;
> + };
> +
> + codec {
> + sound-dai = <&wcd938x 0>, <&swr0 0>, <&rxmacro 0>;
> + };
> + };
> +
> + dai-link@19 {
> + link-name = "WCD Capture";
> + reg = <LPASS_CDC_DMA_TX3>;
> + cpu {
> + sound-dai = <&lpass_cpu LPASS_CDC_DMA_TX3>;
> + };
> +
> + codec {
> + sound-dai = <&wcd938x 1>, <&swr1 0>, <&txmacro 0>;
> + };
> + };
> +
> + dai-link@1 {
> + link-name = "Secondary MI2S Playback";
> + reg = <MI2S_SECONDARY>;
> + cpu {
> + sound-dai = <&lpass_cpu MI2S_SECONDARY>;
> + };
> +
> + codec {
> + sound-dai = <&max98360a>;
> + };
> + };
> +
> + dai-link@5 {
> + link-name = "DP Playback";
> + reg = <LPASS_DP_RX>;
> + cpu {
> + sound-dai = <&lpass_cpu LPASS_DP_RX>;
> + };
> +
> + codec {
> + sound-dai = <&msm_dp>;
Why double tabbed?
> + };
> + };
> +
> + dai-link@25 {
> + link-name = "DMIC Capture";
> + reg = <LPASS_CDC_DMA_VA_TX0>;
> + cpu {
> + sound-dai = <&lpass_cpu LPASS_CDC_DMA_VA_TX0>;
> + };
> +
> + codec {
> + sound-dai = <&vamacro 0>;
> + };
> + };
The order of the nodes seems arbitrary. Is there any sort order that can
be used to avoid conflicts in the future? Maybe the reg property because
that's how we sort the SoC node.
> +};
> +
> &swr0 {
> wcd_rx: wcd938x-rx{
> compatible = "sdw20217010d00";
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 68c7755..57bc5ef 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -2786,6 +2786,9 @@
>
> };
>
> + sound: sound {
Is this really necessary? Certainly it shouldn't be in the SoC node as
it doesn't have a reg property.
> + };
> +
> usb_1_hsphy: phy@88e3000 {
> compatible = "qcom,sc7280-usb-hs-phy",
> "qcom,usb-snps-hs-7nm-phy";
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH RESEND] KVM: x86/pmu: Make top-down.slots event unavailable in supported leaf
From: Sean Christopherson @ 2022-01-05 21:09 UTC (permalink / raw)
To: Like Xu
Cc: Paolo Bonzini, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson,
Joerg Roedel, kvm, linux-kernel
In-Reply-To: <20220105050711.67280-1-likexu@tencent.com>
On Wed, Jan 05, 2022, Like Xu wrote:
> From: Like Xu <likexu@tencent.com>
>
> When we choose to disable the fourth fixed counter TOPDOWN.SLOTS,
> we need to also reduce the length of the 0AH.EBX bit vector, which
> enumerates architecture performance monitoring events, and set
> 0AH.EBX.[bit 7] to 1 if the new value of EAX[31:24] is still > 7.
>
> Fixes: 2e8cd7a3b8287 ("kvm: x86: limit the maximum number of vPMU fixed counters to 3")
> Signed-off-by: Like Xu <likexu@tencent.com>
> ---
> arch/x86/kvm/cpuid.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 0b920e12bb6d..1f0131145296 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -782,6 +782,21 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
> eax.split.mask_length = cap.events_mask_len;
>
> edx.split.num_counters_fixed = min(cap.num_counters_fixed, MAX_FIXED_COUNTERS);
> +
> + /*
> + * The 8th Intel pre-defined architectural event (Topdown Slots) will be supported
> + * if the 4th fixed counter exists && EAX[31:24] > 7 && EBX[7] = 0.
Please wrap at ~80 chars.
> + *
> + * Currently, KVM needs to set EAX[31:24] < 8 or EBX[7] == 1
> + * to make this event unavailable in a consistent way.
> + */
> + if (edx.split.num_counters_fixed < 4) {
> + if (eax.split.mask_length > 7)
> + eax.split.mask_length--;
This will break if there's a bit>7 enumerated in EBX (events_mask) that KVM wants
to expose to the guest. It doesn't cause problems today because bits 31:8 are all
reserved, but that will not always be the case.
We could do
if (edx.split.num_counters_fixed < 4) {
if (eax.split.mask_length == 7)
eax.split.mask_length--;
else
cap.events_mask |= BIT_ULL(7);
}
but I don't see any reason to make this more complex than:
if (edx.split.num_counters_fixed < 4 &&
eax.split.mask_length > 7)
cap.events_mask |= BIT_ULL(7);
> + if (eax.split.mask_length > 7)
> + cap.events_mask |= BIT_ULL(7);
> + }
> +
> edx.split.bit_width_fixed = cap.bit_width_fixed;
> if (cap.version)
> edx.split.anythread_deprecated = 1;
> --
> 2.33.1
>
^ permalink raw reply
* Re: Trying to understand QOM object creation and property linking
From: Alex Bennée @ 2022-01-05 21:02 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Eduardo Habkost, Paolo Bonzini, Daniel P. Berrange, qemu-devel,
Peter Maydell
In-Reply-To: <fbc66bb0-2c15-d789-bbaa-f9c3ba6f81e4@amsat.org>
Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
> Hi Alex,
>
> On 5/1/22 19:03, Alex Bennée wrote:
>> Hi,
>> I'm having a hell of a time trying to create a new SoC+Board model
>> from
>> scratch. The problem comes down to trying to expose some properties to
>> the underlying CPU from my board model. So I have:
<snip>
>> static void pipico_machine_init(MachineState *machine)
>> {
>> PiPicoMachineState *s = PIPICO_MACHINE(machine);
>> ...
>> MemoryRegion *system_memory = get_system_memory();
Hmm this memory is initialised by memory_region_init() so...
>> ...
>> /* initialize external Flash device */
>> memory_region_init_rom(&s->flash, NULL,
>> "pico.flash0", 256 * KiB, &error_fatal);
>> memory_region_add_subregion(system_memory, 0, &s->flash);
>> /* Setup the SOC */
>> object_initialize_child(OBJECT(machine), "soc", &s->soc, TYPE_RP2040);
>> /* link properties from machine the SoC needs */
>> object_property_set_link(OBJECT(&s->soc), "memory",
>> OBJECT(system_memory), &error_fatal);
>> sysbus_realize(SYS_BUS_DEVICE(&s->soc), &error_fatal);
>> The initialisation of the SoC is simple because I can't do much
>> until
>> things are realised:
>> static void rp2040_init(Object *obj)
>> {
>> RP2040State *s = RP2040(obj);
>> int n;
>> fprintf(stderr, "%s: %p\n", __func__, obj);
>> for (n = 0; n < RP2040_NCPUS; n++) {
>> object_initialize_child(obj, "cpu[*]", &s->armv7m[n], TYPE_ARMV7M);
>> qdev_prop_set_string(DEVICE(&s->armv7m[n]), "cpu-type",
>> ARM_CPU_TYPE_NAME("cortex-m0"));
>
> Here for each core you need to initialize a MemoryRegion container, ...
>
>> }
>> }
>> However when I get to realize the SoC itself:
>> static void rp2040_realize(DeviceState *dev, Error **errp)
>> {
>> RP2040State *s = RP2040(dev);
>> Object *obj = OBJECT(dev);
>> int n;
>> if (!s->board_memory) {
>> error_setg(errp, "%s: memory property was not set", __func__);
>> return;
>> }
>> /* initialize internal 16 KB internal ROM */
>> memory_region_init_rom(&s->rom, obj, "rp2040.rom0", 16 * KiB, errp);
>> memory_region_add_subregion(s->board_memory, 0, &s->rom);
>> /* SRAM (Main 256k bank + two 4k banks)*/
>> memory_region_init_ram(&s->sram03, obj, "rp2040.sram03", 256 * KiB, errp);
>> memory_region_add_subregion(s->board_memory, RP2040_SRAM_BASE, &s->sram03);
>> memory_region_init_ram(&s->sram4, obj, "rp2040.sram4", 4 * KiB,
>> errp);
>> memory_region_add_subregion(s->board_memory, RP2040_SRAM4_BASE, &s->sram4);
>> memory_region_init_ram(&s->sram5, obj, "rp2040.sram5", 4 * KiB,
>> errp);
>> memory_region_add_subregion(s->board_memory, RP2040_SRAM5_BASE, &s->sram5);
>> ...
>> for (n = 0; n < RP2040_NCPUS; n++) {
>> /* DeviceState *cpudev = DEVICE(&s->armv7m[i]); */
>> Object *cpuobj = OBJECT(&s->armv7m[n]);
>
> then you add the board_memory in the per-CPU container as subregion,
> ...
Can't be added as a subregion to the container...
qemu-system-arm: ../../softmmu/memory.c:2538: memory_region_add_subregion_common: Assertion `!subregion->container' failed.
>
>> object_property_set_link(cpuobj, "memory",
>> OBJECT(&s->board_memory), errp);
>
> and finally each CPU links its container as its memory bus.
So something like:
object_property_set_link(cpuobj, "memory", OBJECT(s->cpu_mem[n]), errp);
so the CPU sees the container with whatever particular set of memory
regions you want to make visible to that CPU?
<snip>
>> Follow-up questions, does only creating the main memory aliases as
>> part
>> of the SoC make sense? My rational is most of the memory is part of the
>> SoC not the board. I assume later RP2040 based boards may have different
>> flash configs or even external memory.
>> The current (messy) state of my tree can be seen at:
>> https://gitlab.com/stsquad/qemu/-/commits/arm/picopi-rfc
>>
--
Alex Bennée
^ permalink raw reply
* Re: [PATCH] PCI: iproc: Set all 24 bits of PCI class code
From: kernel test robot @ 2022-01-05 21:05 UTC (permalink / raw)
To: Pali Rohár, Roman Bacik, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Bjorn Helgaas
Cc: llvm, kbuild-all, bcm-kernel-feedback-list, linux-pci,
linux-arm-kernel, linux-kernel
In-Reply-To: <20220105093552.27542-1-pali@kernel.org>
Hi "Pali,
I love your patch! Yet something to improve:
[auto build test ERROR on helgaas-pci/next]
[also build test ERROR on v5.16-rc8 next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Pali-Roh-r/PCI-iproc-Set-all-24-bits-of-PCI-class-code/20220105-173704
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: arm-randconfig-r001-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060511.mczwwaNF-lkp@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project d5b6e30ed3acad794dd0aec400e617daffc6cc3d)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
# https://github.com/0day-ci/linux/commit/8ef1acfb84c08a0331930f9a60884fdd6d7c5e88
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Pali-Roh-r/PCI-iproc-Set-all-24-bits-of-PCI-class-code/20220105-173704
git checkout 8ef1acfb84c08a0331930f9a60884fdd6d7c5e88
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/pci/controller/pcie-iproc.c:798:11: error: use of undeclared identifier 'PCI_CLASS_BRIDGE_PCI_NORMAL'
class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
^
1 error generated.
vim +/PCI_CLASS_BRIDGE_PCI_NORMAL +798 drivers/pci/controller/pcie-iproc.c
765
766 static int iproc_pcie_check_link(struct iproc_pcie *pcie)
767 {
768 struct device *dev = pcie->dev;
769 u32 hdr_type, link_ctrl, link_status, class, val;
770 bool link_is_active = false;
771
772 /*
773 * PAXC connects to emulated endpoint devices directly and does not
774 * have a Serdes. Therefore skip the link detection logic here.
775 */
776 if (pcie->ep_is_internal)
777 return 0;
778
779 val = iproc_pcie_read_reg(pcie, IPROC_PCIE_LINK_STATUS);
780 if (!(val & PCIE_PHYLINKUP) || !(val & PCIE_DL_ACTIVE)) {
781 dev_err(dev, "PHY or data link is INACTIVE!\n");
782 return -ENODEV;
783 }
784
785 /* make sure we are not in EP mode */
786 iproc_pci_raw_config_read32(pcie, 0, PCI_HEADER_TYPE, 1, &hdr_type);
787 if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE) {
788 dev_err(dev, "in EP mode, hdr=%#02x\n", hdr_type);
789 return -EFAULT;
790 }
791
792 /* force class to PCI_CLASS_BRIDGE_PCI_NORMAL (0x060400) */
793 #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
794 #define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xffffff
795 iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
796 4, &class);
797 class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK;
> 798 class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
799 iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
800 4, class);
801
802 /* check link status to see if link is active */
803 iproc_pci_raw_config_read32(pcie, 0, IPROC_PCI_EXP_CAP + PCI_EXP_LNKSTA,
804 2, &link_status);
805 if (link_status & PCI_EXP_LNKSTA_NLW)
806 link_is_active = true;
807
808 if (!link_is_active) {
809 /* try GEN 1 link speed */
810 #define PCI_TARGET_LINK_SPEED_MASK 0xf
811 #define PCI_TARGET_LINK_SPEED_GEN2 0x2
812 #define PCI_TARGET_LINK_SPEED_GEN1 0x1
813 iproc_pci_raw_config_read32(pcie, 0,
814 IPROC_PCI_EXP_CAP + PCI_EXP_LNKCTL2,
815 4, &link_ctrl);
816 if ((link_ctrl & PCI_TARGET_LINK_SPEED_MASK) ==
817 PCI_TARGET_LINK_SPEED_GEN2) {
818 link_ctrl &= ~PCI_TARGET_LINK_SPEED_MASK;
819 link_ctrl |= PCI_TARGET_LINK_SPEED_GEN1;
820 iproc_pci_raw_config_write32(pcie, 0,
821 IPROC_PCI_EXP_CAP + PCI_EXP_LNKCTL2,
822 4, link_ctrl);
823 msleep(100);
824
825 iproc_pci_raw_config_read32(pcie, 0,
826 IPROC_PCI_EXP_CAP + PCI_EXP_LNKSTA,
827 2, &link_status);
828 if (link_status & PCI_EXP_LNKSTA_NLW)
829 link_is_active = true;
830 }
831 }
832
833 dev_info(dev, "link: %s\n", link_is_active ? "UP" : "DOWN");
834
835 return link_is_active ? 0 : -ENODEV;
836 }
837
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 0/9] Multigenerational LRU Framework
From: Yu Zhao @ 2022-01-05 21:06 UTC (permalink / raw)
To: SeongJae Park, Borislav Petkov
Cc: Andrew Morton, Linus Torvalds, Andi Kleen, Catalin Marinas,
Dave Hansen, Hillf Danton, Jens Axboe, Jesse Barnes,
Johannes Weiner, Jonathan Corbet, Matthew Wilcox, Mel Gorman,
Michael Larabel, Michal Hocko, Rik van Riel, Vlastimil Babka,
Will Deacon, Ying Huang, linux-arm-kernel, linux-doc,
linux-kernel, linux-mm, page-reclaim, x86
In-Reply-To: <20220105112527.23399-1-sj@kernel.org>
On Wed, Jan 05, 2022 at 11:25:27AM +0000, SeongJae Park wrote:
> On Wed, 5 Jan 2022 03:53:07 -0700 Yu Zhao <yuzhao@google.com> wrote:
>
> > On Wed, Jan 05, 2022 at 08:55:34AM +0000, SeongJae Park wrote:
> > > Hi Yu,
> > >
> > > On Tue, 4 Jan 2022 13:22:19 -0700 Yu Zhao <yuzhao@google.com> wrote:
> [...]
> > > I think similar works are already available out of the box with the latest
> > > mainline tree, though it might be suboptimal in some cases.
> >
> > Ok, I will sound harsh because I hate it when people challenge facts
> > while having no idea what they are talking about.
> >
> > Our jobs are help the leadership make best decisions by providing them
> > with facts, not feeding them crap.
>
> I was using the word "similar", to represent this is only for a rough concept
> level similarity, rather than detailed facts. But, seems it was not enough,
> sorry. Anyway, I will not talk more and thus disturb you having the important
> discussion with leaders here, as you are asking.
First of all, I want to apologize.
I detested what I read, and I still don't like "a rough concept level
similarity" sitting next to a factual statement. But as Borislav has
reminded me, my tone did cross the line. I should have had used an
objective approach to express my (very) different views.
I hope that's all water under the bridge now. And I do plan to carry
on with what I should have had done.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] vfio/pci: Generate more relevant log messages for reset failures
From: Michael S. Tsirkin @ 2022-01-05 21:05 UTC (permalink / raw)
To: Alex Williamson; +Cc: qemu-devel, kraxel
In-Reply-To: <164141259622.4193261.8252690438434562107.stgit@omen>
On Wed, Jan 05, 2022 at 12:56:42PM -0700, Alex Williamson wrote:
> The VFIO_DEVICE_RESET ioctl might be backed by several different reset
> methods, including a device specific reset (ie. custom reset code in
> kernel), an ACPI reset (ie. custom reset code in firmware), FLR, PM,
> and bus resets. This listing is also the default priority order used
> by the kernel for trying reset methods. Traditionally we've had some
> FUD regarding the PM reset as the extent of a "Soft Reset" is not well
> defined in the PCI specification. Therefore we try to guess what type
> of reset a device might use for the VFIO_DEVICE_RESET and insert a bus
> reset via the vfio hot reset interface if we think it could be a PM
> reset.
>
> This results in a couple odd tests for PM reset in our hot reset code,
> as we assume if we don't detect has_pm_reset support that we can't
> reset the device otherwise. Starting with kernel v5.15, the kernel
> exposes a sysfs attribute for devices that can tell us the priority
> order for device resets, so long term (not implemented here) we no
> longer need to play this guessing game, and if permissions allow we
> could manipulate the order ourselves so that we don't need to inject
> our own hot reset.
>
> In the shorter term, implemented here, let's not assume we're out of
> reset methods if we can't perform a hot reset and the device doesn't
> support PM reset. We can use reset_works as the authority, which
> allows us to generate more comprehensible error messages for the case
> when it actually doesn't work.
>
> The impetus for this change is a result of commit d5daff7d3126 ("pcie:
> implement slot power control for pcie root ports"), where powering off
> a slot now results in a device reset. If the slot is powered off as a
> result of qdev_unplug() via the device request event, that device
> request is potentially the result of an unbind operation in the host.
> That unbind operation holds the kernel device lock, which causes the
> VFIO_DEVICE_RESET ioctl to fail (or in the case of some kernels, has
> cleared the flag indicating support of a device reset function). We
> can then end up with an SR-IOV VF device trying to trigger a hot reset,
> which finds that it needs ownership of the PF group to perform such a
> reset, resulting in confusing log messages.
>
> Ultimately the above commit still introduces a log message that we
> didn't have prior on such an unplug, but it's not unjustified to
> perform such a reset, though it might be considered unnecessary.
> Arguably failure to reset the device should always generate some sort
> of meaningful log message.
>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Looks reasonable. Just an extra idea: do we want to maybe validate the
return code from the ioctl? I assume it's something like EBUSY right?
In any case better than what we have now:
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> hw/vfio/pci.c | 44 ++++++++++++++++++++++++++++++++------------
> 1 file changed, 32 insertions(+), 12 deletions(-)
>
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 7b45353ce27f..ea697951556e 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -2224,7 +2224,7 @@ static int vfio_pci_hot_reset(VFIOPCIDevice *vdev, bool single)
> ret = ioctl(vdev->vbasedev.fd, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO, info);
> if (ret && errno != ENOSPC) {
> ret = -errno;
> - if (!vdev->has_pm_reset) {
> + if (!vdev->vbasedev.reset_works) {
> error_report("vfio: Cannot reset device %s, "
> "no available reset mechanism.", vdev->vbasedev.name);
> }
> @@ -2270,7 +2270,7 @@ static int vfio_pci_hot_reset(VFIOPCIDevice *vdev, bool single)
> }
>
> if (!group) {
> - if (!vdev->has_pm_reset) {
> + if (!vdev->vbasedev.reset_works) {
> error_report("vfio: Cannot reset device %s, "
> "depends on group %d which is not owned.",
> vdev->vbasedev.name, devices[i].group_id);
> @@ -3162,6 +3162,8 @@ static void vfio_exitfn(PCIDevice *pdev)
> static void vfio_pci_reset(DeviceState *dev)
> {
> VFIOPCIDevice *vdev = VFIO_PCI(dev);
> + Error *err = NULL;
> + int ret;
>
> trace_vfio_pci_reset(vdev->vbasedev.name);
>
> @@ -3175,26 +3177,44 @@ static void vfio_pci_reset(DeviceState *dev)
> goto post_reset;
> }
>
> - if (vdev->vbasedev.reset_works &&
> - (vdev->has_flr || !vdev->has_pm_reset) &&
> - !ioctl(vdev->vbasedev.fd, VFIO_DEVICE_RESET)) {
> - trace_vfio_pci_reset_flr(vdev->vbasedev.name);
> - goto post_reset;
> + if (vdev->vbasedev.reset_works && (vdev->has_flr || !vdev->has_pm_reset)) {
> + if (!ioctl(vdev->vbasedev.fd, VFIO_DEVICE_RESET)) {
> + trace_vfio_pci_reset_flr(vdev->vbasedev.name);
> + goto post_reset;
> + }
> +
> + error_setg_errno(&err, errno, "Unable to reset device");
> }
>
> /* See if we can do our own bus reset */
> - if (!vfio_pci_hot_reset_one(vdev)) {
> + ret = vfio_pci_hot_reset_one(vdev);
> + if (!ret) {
> goto post_reset;
> }
>
> + if (!err) {
> + error_setg_errno(&err, -ret, "Unable to perform bus reset");
> + }
> +
> /* If nothing else works and the device supports PM reset, use it */
> - if (vdev->vbasedev.reset_works && vdev->has_pm_reset &&
> - !ioctl(vdev->vbasedev.fd, VFIO_DEVICE_RESET)) {
> - trace_vfio_pci_reset_pm(vdev->vbasedev.name);
> - goto post_reset;
> + if (vdev->vbasedev.reset_works && vdev->has_pm_reset) {
> + /* Prefer to report the ioctl failure mode */
> + error_free(err);
> + err = NULL;
> +
> + if (!ioctl(vdev->vbasedev.fd, VFIO_DEVICE_RESET)) {
> + trace_vfio_pci_reset_pm(vdev->vbasedev.name);
> + goto post_reset;
> + }
> +
> + error_setg_errno(&err, errno, "Unable to reset device");
> }
>
> + warn_reportf_err(err, VFIO_MSG_PREFIX, vdev->vbasedev.name);
> + err = NULL;
> +
> post_reset:
> + error_free(err);
> vfio_pci_post_reset(vdev);
> }
>
>
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: sc7280: Add lpass cpu node
From: Stephen Boyd @ 2022-01-05 21:07 UTC (permalink / raw)
To: Srinivasa Rao Mandadapu, agross, bjorn.andersson, devicetree,
dianders, judyhsiao, linux-arm-msm, linux-kernel, robh+dt,
rohitkr, srinivas.kandagatla
Cc: Venkata Prasad Potturu
In-Reply-To: <1641208380-15510-3-git-send-email-quic_srivasam@quicinc.com>
Quoting Srinivasa Rao Mandadapu (2022-01-03 03:12:59)
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index c0d9de3..68c7755 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -17,6 +17,7 @@
> #include <dt-bindings/reset/qcom,sdm845-aoss.h>
> #include <dt-bindings/reset/qcom,sdm845-pdc.h>
> #include <dt-bindings/soc/qcom,rpmh-rsc.h>
> +#include <dt-bindings/sound/qcom,lpass.h>
> #include <dt-bindings/thermal/thermal.h>
>
> / {
> @@ -1840,6 +1841,62 @@
> #size-cells = <0>;
> };
>
> + lpass_cpu: qcom,lpass@3260000 {
audio-subsystem@3260000?
> + compatible = "qcom,sc7280-lpass-cpu";
> + reg = <0 0x3260000 0 0xC000>,
> + <0 0x3280000 0 0x29000>,
> + <0 0x3340000 0 0x29000>,
> + <0 0x336C000 0 0x3000>,
> + <0 0x3987000 0 0x68000>,
> + <0 0x3B00000 0 0x29000>;
> + reg-names = "lpass-rxtx-cdc-dma-lpm",
> + "lpass-rxtx-lpaif",
> + "lpass-va-lpaif",
> + "lpass-va-cdc-dma-lpm",
> + "lpass-hdmiif",
> + "lpass-lpaif";
> +
> + iommus = <&apps_smmu 0x1820 0>,
> + <&apps_smmu 0x1821 0>,
> + <&apps_smmu 0x1832 0>;
> + status = "disabled";
> +
> + power-domains = <&rpmhpd SC7280_LCX>;
> + power-domain-names = "lcx";
> + required-opps = <&rpmhpd_opp_nom>;
> +
> + clocks = <&lpass_aon LPASS_AON_CC_AUDIO_HM_H_CLK>,
> + <&lpasscc LPASS_CORE_CC_SYSNOC_MPORT_CORE_CLK>,
> + <&lpass_audiocc LPASS_AUDIO_CC_CODEC_MEM0_CLK>,
> + <&lpass_audiocc LPASS_AUDIO_CC_CODEC_MEM1_CLK>,
> + <&lpass_audiocc LPASS_AUDIO_CC_CODEC_MEM2_CLK>,
> + <&lpasscc LPASS_CORE_CC_EXT_IF0_IBIT_CLK>,
> + <&lpasscc LPASS_CORE_CC_EXT_IF1_IBIT_CLK>,
> + <&lpass_aon LPASS_AON_CC_VA_MEM0_CLK>;
> + clock-names = "aon_cc_audio_hm_h",
> + "core_cc_sysnoc_mport_core",
> + "audio_cc_codec_mem0",
> + "audio_cc_codec_mem1",
> + "audio_cc_codec_mem2",
> + "core_cc_ext_if0_ibit",
> + "core_cc_ext_if1_ibit",
> + "aon_cc_va_mem0";
Please align these things on " and <.
> +
> + #sound-dai-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
> +
> + interrupt-names = "lpass-irq-lpaif",
> + "lpass-irq-vaif",
> + "lpass-irq-rxtxif",
> + "lpass-irq-hdmi";
Same.
> + };
> +
> vamacro: codec@3370000 {
> compatible = "qcom,sc7280-lpass-va-macro";
> pinctrl-0 = <&dmic01_active>;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH] PCI: iproc: Set all 24 bits of PCI class code
From: kernel test robot @ 2022-01-05 21:05 UTC (permalink / raw)
To: Pali Rohár, Roman Bacik, Lorenzo Pieralisi, Rob Herring,
Krzysztof Wilczyński, Bjorn Helgaas
Cc: llvm, kbuild-all, bcm-kernel-feedback-list, linux-pci,
linux-arm-kernel, linux-kernel
In-Reply-To: <20220105093552.27542-1-pali@kernel.org>
Hi "Pali,
I love your patch! Yet something to improve:
[auto build test ERROR on helgaas-pci/next]
[also build test ERROR on v5.16-rc8 next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Pali-Roh-r/PCI-iproc-Set-all-24-bits-of-PCI-class-code/20220105-173704
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: arm-randconfig-r001-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060511.mczwwaNF-lkp@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project d5b6e30ed3acad794dd0aec400e617daffc6cc3d)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
# https://github.com/0day-ci/linux/commit/8ef1acfb84c08a0331930f9a60884fdd6d7c5e88
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Pali-Roh-r/PCI-iproc-Set-all-24-bits-of-PCI-class-code/20220105-173704
git checkout 8ef1acfb84c08a0331930f9a60884fdd6d7c5e88
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/pci/controller/pcie-iproc.c:798:11: error: use of undeclared identifier 'PCI_CLASS_BRIDGE_PCI_NORMAL'
class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
^
1 error generated.
vim +/PCI_CLASS_BRIDGE_PCI_NORMAL +798 drivers/pci/controller/pcie-iproc.c
765
766 static int iproc_pcie_check_link(struct iproc_pcie *pcie)
767 {
768 struct device *dev = pcie->dev;
769 u32 hdr_type, link_ctrl, link_status, class, val;
770 bool link_is_active = false;
771
772 /*
773 * PAXC connects to emulated endpoint devices directly and does not
774 * have a Serdes. Therefore skip the link detection logic here.
775 */
776 if (pcie->ep_is_internal)
777 return 0;
778
779 val = iproc_pcie_read_reg(pcie, IPROC_PCIE_LINK_STATUS);
780 if (!(val & PCIE_PHYLINKUP) || !(val & PCIE_DL_ACTIVE)) {
781 dev_err(dev, "PHY or data link is INACTIVE!\n");
782 return -ENODEV;
783 }
784
785 /* make sure we are not in EP mode */
786 iproc_pci_raw_config_read32(pcie, 0, PCI_HEADER_TYPE, 1, &hdr_type);
787 if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE) {
788 dev_err(dev, "in EP mode, hdr=%#02x\n", hdr_type);
789 return -EFAULT;
790 }
791
792 /* force class to PCI_CLASS_BRIDGE_PCI_NORMAL (0x060400) */
793 #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
794 #define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xffffff
795 iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
796 4, &class);
797 class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK;
> 798 class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
799 iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
800 4, class);
801
802 /* check link status to see if link is active */
803 iproc_pci_raw_config_read32(pcie, 0, IPROC_PCI_EXP_CAP + PCI_EXP_LNKSTA,
804 2, &link_status);
805 if (link_status & PCI_EXP_LNKSTA_NLW)
806 link_is_active = true;
807
808 if (!link_is_active) {
809 /* try GEN 1 link speed */
810 #define PCI_TARGET_LINK_SPEED_MASK 0xf
811 #define PCI_TARGET_LINK_SPEED_GEN2 0x2
812 #define PCI_TARGET_LINK_SPEED_GEN1 0x1
813 iproc_pci_raw_config_read32(pcie, 0,
814 IPROC_PCI_EXP_CAP + PCI_EXP_LNKCTL2,
815 4, &link_ctrl);
816 if ((link_ctrl & PCI_TARGET_LINK_SPEED_MASK) ==
817 PCI_TARGET_LINK_SPEED_GEN2) {
818 link_ctrl &= ~PCI_TARGET_LINK_SPEED_MASK;
819 link_ctrl |= PCI_TARGET_LINK_SPEED_GEN1;
820 iproc_pci_raw_config_write32(pcie, 0,
821 IPROC_PCI_EXP_CAP + PCI_EXP_LNKCTL2,
822 4, link_ctrl);
823 msleep(100);
824
825 iproc_pci_raw_config_read32(pcie, 0,
826 IPROC_PCI_EXP_CAP + PCI_EXP_LNKSTA,
827 2, &link_status);
828 if (link_status & PCI_EXP_LNKSTA_NLW)
829 link_is_active = true;
830 }
831 }
832
833 dev_info(dev, "link: %s\n", link_is_active ? "UP" : "DOWN");
834
835 return link_is_active ? 0 : -ENODEV;
836 }
837
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] media: st-delta: Fix PM disable depth imbalance in delta_probe
From: kernel test robot @ 2022-01-05 21:05 UTC (permalink / raw)
To: Miaoqian Lin; +Cc: llvm, kbuild-all
In-Reply-To: <20220105115515.12196-1-linmq006@gmail.com>
Hi Miaoqian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on media-tree/master]
[also build test WARNING on v5.16-rc8 next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Miaoqian-Lin/media-st-delta-Fix-PM-disable-depth-imbalance-in-delta_probe/20220105-195600
base: git://linuxtv.org/media_tree.git master
config: riscv-randconfig-r022-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060446.2MV9VJaE-lkp@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project d5b6e30ed3acad794dd0aec400e617daffc6cc3d)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
# https://github.com/0day-ci/linux/commit/df377b6adc1cca5963348f9ac16f033e5da299cb
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Miaoqian-Lin/media-st-delta-Fix-PM-disable-depth-imbalance-in-delta_probe/20220105-195600
git checkout df377b6adc1cca5963348f9ac16f033e5da299cb
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=riscv SHELL=/bin/bash drivers/media/platform/sti/bdisp/ drivers/media/platform/sti/delta/ drivers/media/platform/sti/hva/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> drivers/media/platform/sti/delta/delta-v4l2.c:1901:1: warning: unused label 'disable_pm_runtime' [-Wunused-label]
disable_pm_runtime:
^~~~~~~~~~~~~~~~~~~
1 warning generated.
vim +/disable_pm_runtime +1901 drivers/media/platform/sti/delta/delta-v4l2.c
1812
1813 static int delta_probe(struct platform_device *pdev)
1814 {
1815 struct delta_dev *delta;
1816 struct device *dev = &pdev->dev;
1817 int ret;
1818
1819 delta = devm_kzalloc(dev, sizeof(*delta), GFP_KERNEL);
1820 if (!delta) {
1821 ret = -ENOMEM;
1822 goto err;
1823 }
1824
1825 delta->dev = dev;
1826 delta->pdev = pdev;
1827 platform_set_drvdata(pdev, delta);
1828
1829 mutex_init(&delta->lock);
1830
1831 /* get clock resources */
1832 delta->clk_delta = devm_clk_get(dev, "delta");
1833 if (IS_ERR(delta->clk_delta)) {
1834 dev_dbg(dev, "%s can't get delta clock\n", DELTA_PREFIX);
1835 delta->clk_delta = NULL;
1836 }
1837
1838 delta->clk_st231 = devm_clk_get(dev, "delta-st231");
1839 if (IS_ERR(delta->clk_st231)) {
1840 dev_dbg(dev, "%s can't get delta-st231 clock\n", DELTA_PREFIX);
1841 delta->clk_st231 = NULL;
1842 }
1843
1844 delta->clk_flash_promip = devm_clk_get(dev, "delta-flash-promip");
1845 if (IS_ERR(delta->clk_flash_promip)) {
1846 dev_dbg(dev, "%s can't get delta-flash-promip clock\n",
1847 DELTA_PREFIX);
1848 delta->clk_flash_promip = NULL;
1849 }
1850
1851 /* init pm_runtime used for power management */
1852 pm_runtime_set_autosuspend_delay(dev, DELTA_HW_AUTOSUSPEND_DELAY_MS);
1853 pm_runtime_use_autosuspend(dev);
1854 pm_runtime_set_suspended(dev);
1855 pm_runtime_enable(dev);
1856
1857 /* init firmware ipc channel */
1858 ret = delta_ipc_init(delta);
1859 if (ret) {
1860 dev_err(delta->dev, "%s failed to initialize firmware ipc channel\n",
1861 DELTA_PREFIX);
1862 goto err;
1863 }
1864
1865 /* register all available decoders */
1866 register_decoders(delta);
1867
1868 /* register all supported formats */
1869 register_formats(delta);
1870
1871 /* register on V4L2 */
1872 ret = v4l2_device_register(dev, &delta->v4l2_dev);
1873 if (ret) {
1874 dev_err(delta->dev, "%s failed to register V4L2 device\n",
1875 DELTA_PREFIX);
1876 goto err;
1877 }
1878
1879 delta->work_queue = create_workqueue(DELTA_NAME);
1880 if (!delta->work_queue) {
1881 dev_err(delta->dev, "%s failed to allocate work queue\n",
1882 DELTA_PREFIX);
1883 ret = -ENOMEM;
1884 goto err_v4l2;
1885 }
1886
1887 /* register device */
1888 ret = delta_register_device(delta);
1889 if (ret)
1890 goto err_work_queue;
1891
1892 dev_info(dev, "%s %s registered as /dev/video%d\n",
1893 DELTA_PREFIX, delta->vdev->name, delta->vdev->num);
1894
1895 return 0;
1896
1897 err_work_queue:
1898 destroy_workqueue(delta->work_queue);
1899 err_v4l2:
1900 v4l2_device_unregister(&delta->v4l2_dev);
> 1901 disable_pm_runtime:
1902 pm_runtime_disable(dev);
1903 err:
1904 return ret;
1905 }
1906
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v6 0/9] Multigenerational LRU Framework
From: Yu Zhao @ 2022-01-05 21:06 UTC (permalink / raw)
To: SeongJae Park, Borislav Petkov
Cc: Andrew Morton, Linus Torvalds, Andi Kleen, Catalin Marinas,
Dave Hansen, Hillf Danton, Jens Axboe, Jesse Barnes,
Johannes Weiner, Jonathan Corbet, Matthew Wilcox, Mel Gorman,
Michael Larabel, Michal Hocko, Rik van Riel, Vlastimil Babka,
Will Deacon, Ying Huang, linux-arm-kernel, linux-doc,
linux-kernel, linux-mm, page-reclaim, x86
In-Reply-To: <20220105112527.23399-1-sj@kernel.org>
On Wed, Jan 05, 2022 at 11:25:27AM +0000, SeongJae Park wrote:
> On Wed, 5 Jan 2022 03:53:07 -0700 Yu Zhao <yuzhao@google.com> wrote:
>
> > On Wed, Jan 05, 2022 at 08:55:34AM +0000, SeongJae Park wrote:
> > > Hi Yu,
> > >
> > > On Tue, 4 Jan 2022 13:22:19 -0700 Yu Zhao <yuzhao@google.com> wrote:
> [...]
> > > I think similar works are already available out of the box with the latest
> > > mainline tree, though it might be suboptimal in some cases.
> >
> > Ok, I will sound harsh because I hate it when people challenge facts
> > while having no idea what they are talking about.
> >
> > Our jobs are help the leadership make best decisions by providing them
> > with facts, not feeding them crap.
>
> I was using the word "similar", to represent this is only for a rough concept
> level similarity, rather than detailed facts. But, seems it was not enough,
> sorry. Anyway, I will not talk more and thus disturb you having the important
> discussion with leaders here, as you are asking.
First of all, I want to apologize.
I detested what I read, and I still don't like "a rough concept level
similarity" sitting next to a factual statement. But as Borislav has
reminded me, my tone did cross the line. I should have had used an
objective approach to express my (very) different views.
I hope that's all water under the bridge now. And I do plan to carry
on with what I should have had done.
^ permalink raw reply
* Re: [PATCH v2 3/7] iio: adc: qcom-spmi-rradc: introduce round robin adc
From: kernel test robot @ 2022-01-05 21:05 UTC (permalink / raw)
To: Caleb Connolly, Jonathan Cameron, Lars-Peter Clausen, Rob Herring,
Andy Gross, Bjorn Andersson, Lee Jones, linux-iio, devicetree,
linux-kernel
Cc: kbuild-all
In-Reply-To: <20220105183353.2505744-4-caleb.connolly@linaro.org>
Hi Caleb,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on jic23-iio/togreg lee-mfd/for-mfd-next v5.16-rc8 next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Caleb-Connolly/iio-adc-introduce-Qualcomm-SPMI-Round-Robin-ADC/20220106-023716
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20220106/202201060438.QiDzs9rA-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/167368793a009e8c1ce75b0b8b0965a4574af527
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Caleb-Connolly/iio-adc-introduce-Qualcomm-SPMI-Round-Robin-ADC/20220106-023716
git checkout 167368793a009e8c1ce75b0b8b0965a4574af527
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=sh SHELL=/bin/bash drivers/iio/adc/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/iio/adc/qcom-spmi-rradc.c: In function 'rradc_prepare_batt_id_conversion':
>> drivers/iio/adc/qcom-spmi-rradc.c:624:25: error: implicit declaration of function 'FIELD_PREP' [-Werror=implicit-function-declaration]
624 | FIELD_PREP(BATT_ID_SETTLE_MASK, chip->batt_id_delay);
| ^~~~~~~~~~
cc1: some warnings being treated as errors
vim +/FIELD_PREP +624 drivers/iio/adc/qcom-spmi-rradc.c
607
608 static int rradc_prepare_batt_id_conversion(struct rradc_chip *chip,
609 enum rradc_channel_id chan_id,
610 u16 *data)
611 {
612 int ret, batt_id_delay;
613
614 ret = regmap_update_bits(chip->regmap, chip->base + RR_ADC_BATT_ID_CTRL,
615 RR_ADC_BATT_ID_CTRL_CHANNEL_CONV,
616 RR_ADC_BATT_ID_CTRL_CHANNEL_CONV);
617 if (ret < 0) {
618 dev_err(chip->dev, "Enabling BATT ID channel failed:%d\n", ret);
619 return ret;
620 }
621
622 if (chip->batt_id_delay != -EINVAL) {
623 batt_id_delay =
> 624 FIELD_PREP(BATT_ID_SETTLE_MASK, chip->batt_id_delay);
625 ret = regmap_update_bits(chip->regmap,
626 chip->base + RR_ADC_BATT_ID_CFG,
627 batt_id_delay, batt_id_delay);
628 if (ret < 0) {
629 dev_err(chip->dev,
630 "BATT_ID settling time config failed:%d\n",
631 ret);
632 goto out_disable_batt_id;
633 }
634 }
635
636 ret = regmap_update_bits(chip->regmap,
637 chip->base + RR_ADC_BATT_ID_TRIGGER,
638 RR_ADC_TRIGGER_CTL, RR_ADC_TRIGGER_CTL);
639 if (ret < 0) {
640 dev_err(chip->dev, "BATT_ID trigger set failed:%d\n", ret);
641 goto out_disable_batt_id;
642 }
643
644 ret = rradc_read_status_in_cont_mode(chip, chan_id);
645 if (ret < 0)
646 dev_err(chip->dev, "Error reading in continuous mode:%d\n",
647 ret);
648
649 /*
650 * Reset registers back to default values
651 */
652 ret = regmap_update_bits(chip->regmap,
653 chip->base + RR_ADC_BATT_ID_TRIGGER,
654 RR_ADC_TRIGGER_CTL, 0);
655 if (ret < 0)
656 dev_err(chip->dev, "BATT_ID trigger re-set failed:%d\n", ret);
657
658 out_disable_batt_id:
659 ret = regmap_update_bits(chip->regmap, chip->base + RR_ADC_BATT_ID_CTRL,
660 RR_ADC_BATT_ID_CTRL_CHANNEL_CONV, 0);
661 if (ret < 0)
662 dev_err(chip->dev, "Disabling BATT ID channel failed:%d\n",
663 ret);
664
665 return ret;
666 }
667
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] PCI: iproc: Set all 24 bits of PCI class code
From: kernel test robot @ 2022-01-05 21:05 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20220105093552.27542-1-pali@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 5024 bytes --]
Hi "Pali,
I love your patch! Yet something to improve:
[auto build test ERROR on helgaas-pci/next]
[also build test ERROR on v5.16-rc8 next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Pali-Roh-r/PCI-iproc-Set-all-24-bits-of-PCI-class-code/20220105-173704
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: arm-randconfig-r001-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060511.mczwwaNF-lkp(a)intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project d5b6e30ed3acad794dd0aec400e617daffc6cc3d)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
# https://github.com/0day-ci/linux/commit/8ef1acfb84c08a0331930f9a60884fdd6d7c5e88
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Pali-Roh-r/PCI-iproc-Set-all-24-bits-of-PCI-class-code/20220105-173704
git checkout 8ef1acfb84c08a0331930f9a60884fdd6d7c5e88
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/pci/controller/pcie-iproc.c:798:11: error: use of undeclared identifier 'PCI_CLASS_BRIDGE_PCI_NORMAL'
class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
^
1 error generated.
vim +/PCI_CLASS_BRIDGE_PCI_NORMAL +798 drivers/pci/controller/pcie-iproc.c
765
766 static int iproc_pcie_check_link(struct iproc_pcie *pcie)
767 {
768 struct device *dev = pcie->dev;
769 u32 hdr_type, link_ctrl, link_status, class, val;
770 bool link_is_active = false;
771
772 /*
773 * PAXC connects to emulated endpoint devices directly and does not
774 * have a Serdes. Therefore skip the link detection logic here.
775 */
776 if (pcie->ep_is_internal)
777 return 0;
778
779 val = iproc_pcie_read_reg(pcie, IPROC_PCIE_LINK_STATUS);
780 if (!(val & PCIE_PHYLINKUP) || !(val & PCIE_DL_ACTIVE)) {
781 dev_err(dev, "PHY or data link is INACTIVE!\n");
782 return -ENODEV;
783 }
784
785 /* make sure we are not in EP mode */
786 iproc_pci_raw_config_read32(pcie, 0, PCI_HEADER_TYPE, 1, &hdr_type);
787 if ((hdr_type & 0x7f) != PCI_HEADER_TYPE_BRIDGE) {
788 dev_err(dev, "in EP mode, hdr=%#02x\n", hdr_type);
789 return -EFAULT;
790 }
791
792 /* force class to PCI_CLASS_BRIDGE_PCI_NORMAL (0x060400) */
793 #define PCI_BRIDGE_CTRL_REG_OFFSET 0x43c
794 #define PCI_BRIDGE_CTRL_REG_CLASS_MASK 0xffffff
795 iproc_pci_raw_config_read32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
796 4, &class);
797 class &= ~PCI_BRIDGE_CTRL_REG_CLASS_MASK;
> 798 class |= PCI_CLASS_BRIDGE_PCI_NORMAL;
799 iproc_pci_raw_config_write32(pcie, 0, PCI_BRIDGE_CTRL_REG_OFFSET,
800 4, class);
801
802 /* check link status to see if link is active */
803 iproc_pci_raw_config_read32(pcie, 0, IPROC_PCI_EXP_CAP + PCI_EXP_LNKSTA,
804 2, &link_status);
805 if (link_status & PCI_EXP_LNKSTA_NLW)
806 link_is_active = true;
807
808 if (!link_is_active) {
809 /* try GEN 1 link speed */
810 #define PCI_TARGET_LINK_SPEED_MASK 0xf
811 #define PCI_TARGET_LINK_SPEED_GEN2 0x2
812 #define PCI_TARGET_LINK_SPEED_GEN1 0x1
813 iproc_pci_raw_config_read32(pcie, 0,
814 IPROC_PCI_EXP_CAP + PCI_EXP_LNKCTL2,
815 4, &link_ctrl);
816 if ((link_ctrl & PCI_TARGET_LINK_SPEED_MASK) ==
817 PCI_TARGET_LINK_SPEED_GEN2) {
818 link_ctrl &= ~PCI_TARGET_LINK_SPEED_MASK;
819 link_ctrl |= PCI_TARGET_LINK_SPEED_GEN1;
820 iproc_pci_raw_config_write32(pcie, 0,
821 IPROC_PCI_EXP_CAP + PCI_EXP_LNKCTL2,
822 4, link_ctrl);
823 msleep(100);
824
825 iproc_pci_raw_config_read32(pcie, 0,
826 IPROC_PCI_EXP_CAP + PCI_EXP_LNKSTA,
827 2, &link_status);
828 if (link_status & PCI_EXP_LNKSTA_NLW)
829 link_is_active = true;
830 }
831 }
832
833 dev_info(dev, "link: %s\n", link_is_active ? "UP" : "DOWN");
834
835 return link_is_active ? 0 : -ENODEV;
836 }
837
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* Re: [PATCH] media: st-delta: Fix PM disable depth imbalance in delta_probe
From: kernel test robot @ 2022-01-05 21:05 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20220105115515.12196-1-linmq006@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5285 bytes --]
Hi Miaoqian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on media-tree/master]
[also build test WARNING on v5.16-rc8 next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Miaoqian-Lin/media-st-delta-Fix-PM-disable-depth-imbalance-in-delta_probe/20220105-195600
base: git://linuxtv.org/media_tree.git master
config: riscv-randconfig-r022-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060446.2MV9VJaE-lkp(a)intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project d5b6e30ed3acad794dd0aec400e617daffc6cc3d)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
# https://github.com/0day-ci/linux/commit/df377b6adc1cca5963348f9ac16f033e5da299cb
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Miaoqian-Lin/media-st-delta-Fix-PM-disable-depth-imbalance-in-delta_probe/20220105-195600
git checkout df377b6adc1cca5963348f9ac16f033e5da299cb
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=riscv SHELL=/bin/bash drivers/media/platform/sti/bdisp/ drivers/media/platform/sti/delta/ drivers/media/platform/sti/hva/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> drivers/media/platform/sti/delta/delta-v4l2.c:1901:1: warning: unused label 'disable_pm_runtime' [-Wunused-label]
disable_pm_runtime:
^~~~~~~~~~~~~~~~~~~
1 warning generated.
vim +/disable_pm_runtime +1901 drivers/media/platform/sti/delta/delta-v4l2.c
1812
1813 static int delta_probe(struct platform_device *pdev)
1814 {
1815 struct delta_dev *delta;
1816 struct device *dev = &pdev->dev;
1817 int ret;
1818
1819 delta = devm_kzalloc(dev, sizeof(*delta), GFP_KERNEL);
1820 if (!delta) {
1821 ret = -ENOMEM;
1822 goto err;
1823 }
1824
1825 delta->dev = dev;
1826 delta->pdev = pdev;
1827 platform_set_drvdata(pdev, delta);
1828
1829 mutex_init(&delta->lock);
1830
1831 /* get clock resources */
1832 delta->clk_delta = devm_clk_get(dev, "delta");
1833 if (IS_ERR(delta->clk_delta)) {
1834 dev_dbg(dev, "%s can't get delta clock\n", DELTA_PREFIX);
1835 delta->clk_delta = NULL;
1836 }
1837
1838 delta->clk_st231 = devm_clk_get(dev, "delta-st231");
1839 if (IS_ERR(delta->clk_st231)) {
1840 dev_dbg(dev, "%s can't get delta-st231 clock\n", DELTA_PREFIX);
1841 delta->clk_st231 = NULL;
1842 }
1843
1844 delta->clk_flash_promip = devm_clk_get(dev, "delta-flash-promip");
1845 if (IS_ERR(delta->clk_flash_promip)) {
1846 dev_dbg(dev, "%s can't get delta-flash-promip clock\n",
1847 DELTA_PREFIX);
1848 delta->clk_flash_promip = NULL;
1849 }
1850
1851 /* init pm_runtime used for power management */
1852 pm_runtime_set_autosuspend_delay(dev, DELTA_HW_AUTOSUSPEND_DELAY_MS);
1853 pm_runtime_use_autosuspend(dev);
1854 pm_runtime_set_suspended(dev);
1855 pm_runtime_enable(dev);
1856
1857 /* init firmware ipc channel */
1858 ret = delta_ipc_init(delta);
1859 if (ret) {
1860 dev_err(delta->dev, "%s failed to initialize firmware ipc channel\n",
1861 DELTA_PREFIX);
1862 goto err;
1863 }
1864
1865 /* register all available decoders */
1866 register_decoders(delta);
1867
1868 /* register all supported formats */
1869 register_formats(delta);
1870
1871 /* register on V4L2 */
1872 ret = v4l2_device_register(dev, &delta->v4l2_dev);
1873 if (ret) {
1874 dev_err(delta->dev, "%s failed to register V4L2 device\n",
1875 DELTA_PREFIX);
1876 goto err;
1877 }
1878
1879 delta->work_queue = create_workqueue(DELTA_NAME);
1880 if (!delta->work_queue) {
1881 dev_err(delta->dev, "%s failed to allocate work queue\n",
1882 DELTA_PREFIX);
1883 ret = -ENOMEM;
1884 goto err_v4l2;
1885 }
1886
1887 /* register device */
1888 ret = delta_register_device(delta);
1889 if (ret)
1890 goto err_work_queue;
1891
1892 dev_info(dev, "%s %s registered as /dev/video%d\n",
1893 DELTA_PREFIX, delta->vdev->name, delta->vdev->num);
1894
1895 return 0;
1896
1897 err_work_queue:
1898 destroy_workqueue(delta->work_queue);
1899 err_v4l2:
1900 v4l2_device_unregister(&delta->v4l2_dev);
> 1901 disable_pm_runtime:
1902 pm_runtime_disable(dev);
1903 err:
1904 return ret;
1905 }
1906
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* Re: [PATCH v2 3/7] iio: adc: qcom-spmi-rradc: introduce round robin adc
From: kernel test robot @ 2022-01-05 21:05 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20220105183353.2505744-4-caleb.connolly@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 4357 bytes --]
Hi Caleb,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on jic23-iio/togreg lee-mfd/for-mfd-next v5.16-rc8 next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Caleb-Connolly/iio-adc-introduce-Qualcomm-SPMI-Round-Robin-ADC/20220106-023716
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20220106/202201060438.QiDzs9rA-lkp(a)intel.com/config)
compiler: sh4-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/167368793a009e8c1ce75b0b8b0965a4574af527
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Caleb-Connolly/iio-adc-introduce-Qualcomm-SPMI-Round-Robin-ADC/20220106-023716
git checkout 167368793a009e8c1ce75b0b8b0965a4574af527
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=sh SHELL=/bin/bash drivers/iio/adc/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/iio/adc/qcom-spmi-rradc.c: In function 'rradc_prepare_batt_id_conversion':
>> drivers/iio/adc/qcom-spmi-rradc.c:624:25: error: implicit declaration of function 'FIELD_PREP' [-Werror=implicit-function-declaration]
624 | FIELD_PREP(BATT_ID_SETTLE_MASK, chip->batt_id_delay);
| ^~~~~~~~~~
cc1: some warnings being treated as errors
vim +/FIELD_PREP +624 drivers/iio/adc/qcom-spmi-rradc.c
607
608 static int rradc_prepare_batt_id_conversion(struct rradc_chip *chip,
609 enum rradc_channel_id chan_id,
610 u16 *data)
611 {
612 int ret, batt_id_delay;
613
614 ret = regmap_update_bits(chip->regmap, chip->base + RR_ADC_BATT_ID_CTRL,
615 RR_ADC_BATT_ID_CTRL_CHANNEL_CONV,
616 RR_ADC_BATT_ID_CTRL_CHANNEL_CONV);
617 if (ret < 0) {
618 dev_err(chip->dev, "Enabling BATT ID channel failed:%d\n", ret);
619 return ret;
620 }
621
622 if (chip->batt_id_delay != -EINVAL) {
623 batt_id_delay =
> 624 FIELD_PREP(BATT_ID_SETTLE_MASK, chip->batt_id_delay);
625 ret = regmap_update_bits(chip->regmap,
626 chip->base + RR_ADC_BATT_ID_CFG,
627 batt_id_delay, batt_id_delay);
628 if (ret < 0) {
629 dev_err(chip->dev,
630 "BATT_ID settling time config failed:%d\n",
631 ret);
632 goto out_disable_batt_id;
633 }
634 }
635
636 ret = regmap_update_bits(chip->regmap,
637 chip->base + RR_ADC_BATT_ID_TRIGGER,
638 RR_ADC_TRIGGER_CTL, RR_ADC_TRIGGER_CTL);
639 if (ret < 0) {
640 dev_err(chip->dev, "BATT_ID trigger set failed:%d\n", ret);
641 goto out_disable_batt_id;
642 }
643
644 ret = rradc_read_status_in_cont_mode(chip, chan_id);
645 if (ret < 0)
646 dev_err(chip->dev, "Error reading in continuous mode:%d\n",
647 ret);
648
649 /*
650 * Reset registers back to default values
651 */
652 ret = regmap_update_bits(chip->regmap,
653 chip->base + RR_ADC_BATT_ID_TRIGGER,
654 RR_ADC_TRIGGER_CTL, 0);
655 if (ret < 0)
656 dev_err(chip->dev, "BATT_ID trigger re-set failed:%d\n", ret);
657
658 out_disable_batt_id:
659 ret = regmap_update_bits(chip->regmap, chip->base + RR_ADC_BATT_ID_CTRL,
660 RR_ADC_BATT_ID_CTRL_CHANNEL_CONV, 0);
661 if (ret < 0)
662 dev_err(chip->dev, "Disabling BATT ID channel failed:%d\n",
663 ret);
664
665 return ret;
666 }
667
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* Re: [PATCH 4/9] checkout-index: expand sparse checkout compatibility tests
From: Elijah Newren @ 2022-01-05 21:04 UTC (permalink / raw)
To: Victoria Dye via GitGitGadget
Cc: Git Mailing List, Derrick Stolee, Junio C Hamano, Victoria Dye
In-Reply-To: <e6a8671f6be5afad9a495be66c0735f6b741c844.1641317820.git.gitgitgadget@gmail.com>
On Tue, Jan 4, 2022 at 9:37 AM Victoria Dye via GitGitGadget
<gitgitgadget@gmail.com> wrote:
>
> From: Victoria Dye <vdye@github.com>
>
> Add tests to cover `checkout-index`, with a focus on cases interesting in a
> sparse checkout (e.g., files specified outside sparse checkout definition).
> New tests are intended to serve as a baseline for expected behavior and
> performance when integrating `checkout-index` with the sparse index.
>
> Signed-off-by: Victoria Dye <vdye@github.com>
> ---
> t/perf/p2000-sparse-operations.sh | 1 +
> t/t1092-sparse-checkout-compatibility.sh | 54 ++++++++++++++++++++++++
> 2 files changed, 55 insertions(+)
>
> diff --git a/t/perf/p2000-sparse-operations.sh b/t/perf/p2000-sparse-operations.sh
> index cb777c74a24..54f8602f3c1 100755
> --- a/t/perf/p2000-sparse-operations.sh
> +++ b/t/perf/p2000-sparse-operations.sh
> @@ -117,5 +117,6 @@ test_perf_on_all git diff
> test_perf_on_all git diff --cached
> test_perf_on_all git blame $SPARSE_CONE/a
> test_perf_on_all git blame $SPARSE_CONE/f3/a
> +test_perf_on_all git checkout-index -f --all
>
> test_done
> diff --git a/t/t1092-sparse-checkout-compatibility.sh b/t/t1092-sparse-checkout-compatibility.sh
> index 05587361452..db7ad41109b 100755
> --- a/t/t1092-sparse-checkout-compatibility.sh
> +++ b/t/t1092-sparse-checkout-compatibility.sh
> @@ -755,6 +755,60 @@ test_expect_success 'cherry-pick with conflicts' '
> test_all_match test_must_fail git cherry-pick to-cherry-pick
> '
>
> +test_expect_success 'checkout-index inside sparse definition' '
> + init_repos &&
> +
> + run_on_all rm -f deep/a &&
> + test_all_match git checkout-index -- deep/a &&
> + test_all_match git status --porcelain=v2 &&
> +
> + echo test >>new-a &&
> + run_on_all cp ../new-a a &&
> + test_all_match test_must_fail git checkout-index -- a &&
> + test_all_match git checkout-index -f -- a &&
> + test_all_match git status --porcelain=v2
> +'
> +
> +test_expect_success 'checkout-index outside sparse definition' '
> + init_repos &&
> +
> + # File does not exist on disk yet for sparse checkouts, so checkout-index
> + # succeeds without -f
> + test_sparse_match git checkout-index -- folder1/a &&
Whoa, um, what is `git checkout-index -- folder1/a` even supposed to
mean with the sparse-index and cone mode? That's an individual file,
so should folder1 and everything under it have the SKIP_WORKTREE bit
cleared? Should folder1 just stop being a sparse directory, with all
siblings of folder1/a retaining the SKIP_WORKTREE bit (so folder1/0
could become a sparse directory) while folder1/a loses the
SKIP_WORKTREE bit, kind of violating cone mode but perhaps just until
the next sparse-checkout reapply?
The test sadly doesn't look at the SKIP_WORKTREE bits at all, which
feels like an important oversight (unless you meant to test this
later?). Especially since my manual testing shows that this test
leaves the files as SKIP_WORKTREE despite writing the files to the
working tree. I think the present-despite-skip-worktree problem I've
discussed elsewhere is growing in importance rather than shrinking;
you don't need to address that problem with this series but I raise it
mostly so we're aware to at least test it. I'll keep reading to see
if you mention this or fix it up in subsequent patches.
> + test_cmp sparse-checkout/folder1/a sparse-index/folder1/a &&
> + test_cmp sparse-checkout/folder1/a full-checkout/folder1/a &&
> +
> + run_on_sparse rm -rf folder1 &&
> + echo test >new-a &&
> + run_on_sparse mkdir -p folder1 &&
> + run_on_all cp ../new-a folder1/a &&
> +
> + test_all_match test_must_fail git checkout-index -- folder1/a &&
> + test_all_match git checkout-index -f -- folder1/a &&
> + test_cmp sparse-checkout/folder1/a sparse-index/folder1/a &&
> + test_cmp sparse-checkout/folder1/a full-checkout/folder1/a
> +'
> +
> +test_expect_success 'checkout-index with folders' '
> + init_repos &&
> +
> + # Inside checkout definition
> + test_all_match test_must_fail git checkout-index -f -- deep/ &&
> +
> + # Outside checkout definition
> + test_all_match test_must_fail git checkout-index -f -- folder1/
Passing a directory to checkout-index? I'm glad they all immediately
fail, but is the plan just to make sure that this continues? I'm not
sure what could make sense otherwise. You've piqued my curiosity;
I'll keep reading the series to see.
> +'
> +
> +# NEEDSWORK: even in sparse checkouts, checkout-index --all will create all
> +# files (even those outside the sparse definition) on disk. However, these files
> +# don't appear in the percentage of tracked files in git status.
Ah, so you _are_ noticing the present-despite-SKIP_WORKTREE files. I
think it might be nice to test for these a bit earlier, but it's nice
to see some test here for them.
I think that present-despite-SKIP_WORKTREE files is an erroneous
condition, one we should avoid triggering, and one we should help
users clean up from. For checkout-index, the fact that it currently
makes more of these files is buggy. It should either (1) clear the
SKIP_WORKTREE bit when it writes the files to the working tree, or (2)
avoid writing the files to the working tree.
And if we choose (1), there's already a --no-create option we could
piggy-back on to allow folks to not write the SKIP_WORKTREE files.
> +test_expect_failure 'checkout-index --all' '
> + init_repos &&
> +
> + test_all_match git checkout-index --all &&
> + test_sparse_match test_path_is_missing folder1
Ah, it looks like you're choosing (2). That may be fine, but an
interesting anecdote:
While attempting to adopt sparse checkouts at $DAYJOB (and
particularly using cone mode), we found the code structure just didn't
quite work. We needed some directories to be ignored for sparse
checkouts to be meaningful at all, but we had some files that were
siblings to those directories that were needed for builds to function.
We came up with a hack to "add a few files back", using "git
checkout-index -- $FILENAME". We expected that hack to write the
listed file(s) to the working tree -- though I think we also had logic
to then run the stuff we needed and then delete these temporary files.
We used this hack starting in Feb 2020, and eventually restructured
the code to not need this hack in Feb 2021. I'll have to mull over
whether your choice of option (2) might cause us some problems if
someone (a) uses a new git version to (b) access an old version of our
code and (c) really wants to work with a sparse checkout (since the
"checkout-index" stuff was part of the build logic checked into the
code). I think your change here is fine (because not using sparse
checkouts is an option, we told folks it was experimental, and those
are old versions that are only getting security fixes in special
circumstances), but let me think about it for a bit...
> +'
> +
> test_expect_success 'clean' '
> init_repos &&
>
> --
> gitgitgadget
^ permalink raw reply
* Re: [PATCH v2 2/2] update-index: refresh should rewrite index in case of racy timestamps
From: Junio C Hamano @ 2022-01-05 21:03 UTC (permalink / raw)
To: Marc Strapetz via GitGitGadget; +Cc: git, Marc Strapetz
In-Reply-To: <dfeabf6af15dfab06bde1ec7dcc2d0576497be9b.1641388523.git.gitgitgadget@gmail.com>
"Marc Strapetz via GitGitGadget" <gitgitgadget@gmail.com> writes:
> +test_expect_success '--refresh has no racy timestamps to fix' '
> + reset_files &&
> + test-tool chmtime =1234567891 .git/index &&
Don't some people use Git on VFAT where the time resolution is 2
seconds? 1234567890 and 1234567891 differ only by one second, so
chmtime may not be able to store one of them exactly, so I am not
sure if this guarantees "no racy timestamps to fix".
^ permalink raw reply
* Re: [Buildroot] [PATCH 4/4] package/android-tools: add host gcc >= 5 dependency
From: Yann E. MORIN @ 2022-01-05 21:02 UTC (permalink / raw)
To: Fabrice Fontaine
Cc: Marcus Folkesson, Antoine Tenart, Thomas Petazzoni, buildroot,
Clayton Shotwell, Matt Weber
In-Reply-To: <20220105180402.388388-4-fontaine.fabrice@gmail.com>
Fabrice, All,
On 2022-01-05 19:04 +0100, Fabrice Fontaine spake thusly:
> Commit 56d9b887685c86fd4fbadda247cdbe733d499e81 forgot to add host
> gcc >= 5 dependency
>
> Fixes:
> - No autobuilder failures (yet)
>
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
> package/android-tools/Config.in.host | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/package/android-tools/Config.in.host b/package/android-tools/Config.in.host
> index 433f4e384f..576e53e8b5 100644
> --- a/package/android-tools/Config.in.host
> +++ b/package/android-tools/Config.in.host
> @@ -10,12 +10,16 @@ config BR2_PACKAGE_HOST_ANDROID_TOOLS
> if BR2_PACKAGE_HOST_ANDROID_TOOLS
>
> config BR2_PACKAGE_HOST_ANDROID_TOOLS_FASTBOOT
> + depends on BR2_HOST_GCC_AT_LEAST_5 # host-libselinux -> host-libsepol
> bool "fastboot"
> help
> This option will build and install the fastboot utility for
> the host, which can be used to reflash target devices
> implementing the fastboot protocol.
>
> +comment "fastboot needs a toolchain w/ host gcc >= 5"
> + depends on !BR2_HOST_GCC_AT_LEAST_5
> +
> config BR2_PACKAGE_HOST_ANDROID_TOOLS_ADB
> bool "adb"
> help
> @@ -24,10 +28,14 @@ config BR2_PACKAGE_HOST_ANDROID_TOOLS_ADB
> implementing the ADB protocol.
>
> config BR2_PACKAGE_HOST_ANDROID_TOOLS_EXT4_UTILS
> + depends on BR2_HOST_GCC_AT_LEAST_5 # host-libselinux -> host-libsepol
$ make check-package
package/android-tools/Config.in.host:14: attributes order: type, default, depends on, select, help (http://nightly.buildroot.org/#_config_files)
package/android-tools/Config.in.host:32: attributes order: type, default, depends on, select, help (http://nightly.buildroot.org/#_config_files)
Applied to master after fixing this, thanks.
Regards,
Yann E. MORIN.
> bool "ext4 utils"
> help
> This option will build and install the ext4 utils for the
> host, i.e. make_ext4fs, ext4fixup, ext2simg, img2simg,
> simg2img and simg2simg.
>
> +comment "ext4 utils needs a toolchain w/ host gcc >= 5"
> + depends on !BR2_HOST_GCC_AT_LEAST_5
> +
> endif
> --
> 2.34.1
>
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.