* Re: [PATCH RESEND v10 5/5] ASoC: cs40l50: Support I2S streaming to CS40L50
From: James Ogletree @ 2024-05-29 22:03 UTC (permalink / raw)
To: James Ogletree, Mark Brown
Cc: Dmitry Torokhov, robh+dt@kernel.org, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Jeff LaBundy,
open list:CIRRUS LOGIC HAPTIC DRIVERS,
open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
David Rhodes
In-Reply-To: <425AC5F6-6324-41F8-993F-E8B91DDEFC23@cirrus.com>
> On Apr 8, 2024, at 10:32 AM, James Ogletree <jogletre@opensource.cirrus.com> wrote:
>
> Introduce support for Cirrus Logic Device CS40L50: a
> haptic driver with waveform memory, integrated DSP,
> and closed-loop algorithms.
>
> The ASoC driver enables I2S streaming to the device.
>
> Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
> Signed-off-by: James Ogletree <jogletre@opensource.cirrus.com>
> ---
> MAINTAINERS | 1 +
> sound/soc/codecs/Kconfig | 11 ++
> sound/soc/codecs/Makefile | 2 +
> sound/soc/codecs/cs40l50-codec.c | 308 +++++++++++++++++++++++++++++++
> 4 files changed, 322 insertions(+)
> create mode 100644 sound/soc/codecs/cs40l50-codec.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 49c2e6e57b09..62701b13f741 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4943,6 +4943,7 @@ F: Documentation/devicetree/bindings/input/cirrus,cs40l50.yaml
> F: drivers/input/misc/cs40l*
> F: drivers/mfd/cs40l*
> F: include/linux/mfd/cs40l*
> +F: sound/soc/codecs/cs40l*
>
> CIRRUS LOGIC DSP FIRMWARE DRIVER
> M: Simon Trimmer <simont@opensource.cirrus.com>
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index f1e1dbc509f6..1a81bedfdbe3 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -73,6 +73,7 @@ config SND_SOC_ALL_CODECS
> imply SND_SOC_CS35L56_I2C
> imply SND_SOC_CS35L56_SPI
> imply SND_SOC_CS35L56_SDW
> + imply SND_SOC_CS40L50
> imply SND_SOC_CS42L42
> imply SND_SOC_CS42L42_SDW
> imply SND_SOC_CS42L43
> @@ -800,6 +801,16 @@ config SND_SOC_CS35L56_SDW
> help
> Enable support for Cirrus Logic CS35L56 boosted amplifier with SoundWire control
>
> +config SND_SOC_CS40L50
> + tristate "Cirrus Logic CS40L50 CODEC"
> + depends on MFD_CS40L50_CORE
> + help
> + This option enables support for I2S streaming to Cirrus Logic CS40L50.
> +
> + CS40L50 is a haptic driver with waveform memory, an integrated
> + DSP, and closed-loop algorithms. If built as a module, it will be
> + called snd-soc-cs40l50.
> +
> config SND_SOC_CS42L42_CORE
> tristate
>
> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
> index a87e56938ce5..7e31f000774a 100644
> --- a/sound/soc/codecs/Makefile
> +++ b/sound/soc/codecs/Makefile
> @@ -74,6 +74,7 @@ snd-soc-cs35l56-shared-objs := cs35l56-shared.o
> snd-soc-cs35l56-i2c-objs := cs35l56-i2c.o
> snd-soc-cs35l56-spi-objs := cs35l56-spi.o
> snd-soc-cs35l56-sdw-objs := cs35l56-sdw.o
> +snd-soc-cs40l50-objs := cs40l50-codec.o
> snd-soc-cs42l42-objs := cs42l42.o
> snd-soc-cs42l42-i2c-objs := cs42l42-i2c.o
> snd-soc-cs42l42-sdw-objs := cs42l42-sdw.o
> @@ -460,6 +461,7 @@ obj-$(CONFIG_SND_SOC_CS35L56_SHARED) += snd-soc-cs35l56-shared.o
> obj-$(CONFIG_SND_SOC_CS35L56_I2C) += snd-soc-cs35l56-i2c.o
> obj-$(CONFIG_SND_SOC_CS35L56_SPI) += snd-soc-cs35l56-spi.o
> obj-$(CONFIG_SND_SOC_CS35L56_SDW) += snd-soc-cs35l56-sdw.o
> +obj-$(CONFIG_SND_SOC_CS40L50) += snd-soc-cs40l50.o
> obj-$(CONFIG_SND_SOC_CS42L42_CORE) += snd-soc-cs42l42.o
> obj-$(CONFIG_SND_SOC_CS42L42) += snd-soc-cs42l42-i2c.o
> obj-$(CONFIG_SND_SOC_CS42L42_SDW) += snd-soc-cs42l42-sdw.o
> diff --git a/sound/soc/codecs/cs40l50-codec.c b/sound/soc/codecs/cs40l50-codec.c
> new file mode 100644
> index 000000000000..6d4a0970b219
> --- /dev/null
> +++ b/sound/soc/codecs/cs40l50-codec.c
> @@ -0,0 +1,308 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// CS40L50 Advanced Haptic Driver with waveform memory,
> +// integrated DSP, and closed-loop algorithms
> +//
> +// Copyright 2024 Cirrus Logic, Inc.
> +//
> +// Author: James Ogletree <james.ogletree@cirrus.com>
> +
> +#include <linux/bitfield.h>
> +#include <linux/mfd/cs40l50.h>
> +#include <linux/pm_runtime.h>
> +#include <sound/pcm_params.h>
> +#include <sound/soc.h>
> +
> +#define CS40L50_REFCLK_INPUT 0x2C04
> +#define CS40L50_ASP_CONTROL2 0x4808
> +#define CS40L50_ASP_DATA_CONTROL5 0x4840
> +
> +/* PLL Config */
> +#define CS40L50_PLL_REFCLK_BCLK 0x0
> +#define CS40L50_PLL_REFCLK_MCLK 0x5
> +#define CS40L50_PLL_REEFCLK_MCLK_CFG 0x00
> +#define CS40L50_PLL_REFCLK_LOOP_MASK BIT(11)
> +#define CS40L50_PLL_REFCLK_OPEN_LOOP 1
> +#define CS40L50_PLL_REFCLK_CLOSED_LOOP 0
> +#define CS40L50_PLL_REFCLK_LOOP_SHIFT 11
> +#define CS40L50_PLL_REFCLK_FREQ_MASK GENMASK(10, 5)
> +#define CS40L50_PLL_REFCLK_FREQ_SHIFT 5
> +#define CS40L50_PLL_REFCLK_SEL_MASK GENMASK(2, 0)
> +#define CS40L50_BCLK_RATIO_DEFAULT 32
> +
> +/* ASP Config */
> +#define CS40L50_ASP_RX_WIDTH_SHIFT 24
> +#define CS40L50_ASP_RX_WIDTH_MASK GENMASK(31, 24)
> +#define CS40L50_ASP_RX_WL_MASK GENMASK(5, 0)
> +#define CS40L50_ASP_FSYNC_INV_MASK BIT(2)
> +#define CS40L50_ASP_BCLK_INV_MASK BIT(6)
> +#define CS40L50_ASP_FMT_MASK GENMASK(10, 8)
> +#define CS40L50_ASP_FMT_I2S 0x2
> +
> +struct cs40l50_pll_config {
> + unsigned int freq;
> + unsigned int cfg;
> +};
> +
> +struct cs40l50_codec {
> + struct device *dev;
> + struct regmap *regmap;
> + unsigned int daifmt;
> + unsigned int bclk_ratio;
> + unsigned int rate;
> +};
> +
> +static const struct cs40l50_pll_config cs40l50_pll_cfg[] = {
> + { 32768, 0x00 },
> + { 1536000, 0x1B },
> + { 3072000, 0x21 },
> + { 6144000, 0x28 },
> + { 9600000, 0x30 },
> + { 12288000, 0x33 },
> +};
> +
> +static int cs40l50_get_clk_config(unsigned int freq, unsigned int *cfg)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(cs40l50_pll_cfg); i++) {
> + if (cs40l50_pll_cfg[i].freq == freq) {
> + *cfg = cs40l50_pll_cfg[i].cfg;
> + return 0;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int cs40l50_swap_ext_clk(struct cs40l50_codec *codec, unsigned int clk_src)
> +{
> + unsigned int cfg;
> + int ret;
> +
> + switch (clk_src) {
> + case CS40L50_PLL_REFCLK_BCLK:
> + ret = cs40l50_get_clk_config(codec->bclk_ratio * codec->rate, &cfg);
> + if (ret)
> + return ret;
> + break;
> + case CS40L50_PLL_REFCLK_MCLK:
> + cfg = CS40L50_PLL_REEFCLK_MCLK_CFG;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + ret = regmap_update_bits(codec->regmap, CS40L50_REFCLK_INPUT,
> + CS40L50_PLL_REFCLK_LOOP_MASK,
> + CS40L50_PLL_REFCLK_OPEN_LOOP <<
> + CS40L50_PLL_REFCLK_LOOP_SHIFT);
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(codec->regmap, CS40L50_REFCLK_INPUT,
> + CS40L50_PLL_REFCLK_FREQ_MASK |
> + CS40L50_PLL_REFCLK_SEL_MASK,
> + (cfg << CS40L50_PLL_REFCLK_FREQ_SHIFT) | clk_src);
> + if (ret)
> + return ret;
> +
> + return regmap_update_bits(codec->regmap, CS40L50_REFCLK_INPUT,
> + CS40L50_PLL_REFCLK_LOOP_MASK,
> + CS40L50_PLL_REFCLK_CLOSED_LOOP <<
> + CS40L50_PLL_REFCLK_LOOP_SHIFT);
> +}
> +
> +static int cs40l50_clk_en(struct snd_soc_dapm_widget *w,
> + struct snd_kcontrol *kcontrol,
> + int event)
> +{
> + struct snd_soc_component *comp = snd_soc_dapm_to_component(w->dapm);
> + struct cs40l50_codec *codec = snd_soc_component_get_drvdata(comp);
> + int ret;
> +
> + switch (event) {
> + case SND_SOC_DAPM_POST_PMU:
> + ret = cs40l50_dsp_write(codec->dev, codec->regmap, CS40L50_STOP_PLAYBACK);
> + if (ret)
> + return ret;
> +
> + ret = cs40l50_dsp_write(codec->dev, codec->regmap, CS40L50_START_I2S);
> + if (ret)
> + return ret;
> +
> + ret = cs40l50_swap_ext_clk(codec, CS40L50_PLL_REFCLK_BCLK);
> + if (ret)
> + return ret;
> + break;
> + case SND_SOC_DAPM_PRE_PMD:
> + ret = cs40l50_swap_ext_clk(codec, CS40L50_PLL_REFCLK_MCLK);
> + if (ret)
> + return ret;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static const struct snd_soc_dapm_widget cs40l50_dapm_widgets[] = {
> + SND_SOC_DAPM_SUPPLY_S("ASP PLL", 0, SND_SOC_NOPM, 0, 0, cs40l50_clk_en,
> + SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD),
> + SND_SOC_DAPM_AIF_IN("ASPRX1", NULL, 0, SND_SOC_NOPM, 0, 0),
> + SND_SOC_DAPM_AIF_IN("ASPRX2", NULL, 0, SND_SOC_NOPM, 0, 0),
> + SND_SOC_DAPM_OUTPUT("OUT"),
> +};
> +
> +static const struct snd_soc_dapm_route cs40l50_dapm_routes[] = {
> + { "ASP Playback", NULL, "ASP PLL" },
> + { "ASPRX1", NULL, "ASP Playback" },
> + { "ASPRX2", NULL, "ASP Playback" },
> +
> + { "OUT", NULL, "ASPRX1" },
> + { "OUT", NULL, "ASPRX2" },
> +};
> +
> +static int cs40l50_set_dai_fmt(struct snd_soc_dai *codec_dai, unsigned int fmt)
> +{
> + struct cs40l50_codec *codec = snd_soc_component_get_drvdata(codec_dai->component);
> +
> + if ((fmt & SND_SOC_DAIFMT_MASTER_MASK) != SND_SOC_DAIFMT_CBC_CFC)
> + return -EINVAL;
> +
> + switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
> + case SND_SOC_DAIFMT_NB_NF:
> + codec->daifmt = 0;
> + break;
> + case SND_SOC_DAIFMT_NB_IF:
> + codec->daifmt = CS40L50_ASP_FSYNC_INV_MASK;
> + break;
> + case SND_SOC_DAIFMT_IB_NF:
> + codec->daifmt = CS40L50_ASP_BCLK_INV_MASK;
> + break;
> + case SND_SOC_DAIFMT_IB_IF:
> + codec->daifmt = CS40L50_ASP_FSYNC_INV_MASK | CS40L50_ASP_BCLK_INV_MASK;
> + break;
> + default:
> + dev_err(codec->dev, "Invalid clock invert\n");
> + return -EINVAL;
> + }
> +
> + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
> + case SND_SOC_DAIFMT_I2S:
> + codec->daifmt |= FIELD_PREP(CS40L50_ASP_FMT_MASK, CS40L50_ASP_FMT_I2S);
> + break;
> + default:
> + dev_err(codec->dev, "Unsupported DAI format\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int cs40l50_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *dai)
> +{
> + struct cs40l50_codec *codec = snd_soc_component_get_drvdata(dai->component);
> + unsigned int asp_rx_wl = params_width(params);
> + int ret;
> +
> + codec->rate = params_rate(params);
> +
> + ret = regmap_update_bits(codec->regmap, CS40L50_ASP_DATA_CONTROL5,
> + CS40L50_ASP_RX_WL_MASK, asp_rx_wl);
> + if (ret)
> + return ret;
> +
> + codec->daifmt |= (asp_rx_wl << CS40L50_ASP_RX_WIDTH_SHIFT);
> +
> + return regmap_update_bits(codec->regmap, CS40L50_ASP_CONTROL2,
> + CS40L50_ASP_FSYNC_INV_MASK |
> + CS40L50_ASP_BCLK_INV_MASK |
> + CS40L50_ASP_FMT_MASK |
> + CS40L50_ASP_RX_WIDTH_MASK, codec->daifmt);
> +}
> +
> +static int cs40l50_set_dai_bclk_ratio(struct snd_soc_dai *dai, unsigned int ratio)
> +{
> + struct cs40l50_codec *codec = snd_soc_component_get_drvdata(dai->component);
> +
> + codec->bclk_ratio = ratio;
> +
> + return 0;
> +}
> +
> +static const struct snd_soc_dai_ops cs40l50_dai_ops = {
> + .set_fmt = cs40l50_set_dai_fmt,
> + .set_bclk_ratio = cs40l50_set_dai_bclk_ratio,
> + .hw_params = cs40l50_hw_params,
> +};
> +
> +static struct snd_soc_dai_driver cs40l50_dai[] = {
> + {
> + .name = "cs40l50-pcm",
> + .id = 0,
> + .playback = {
> + .stream_name = "ASP Playback",
> + .channels_min = 1,
> + .channels_max = 2,
> + .rates = SNDRV_PCM_RATE_48000,
> + .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE,
> + },
> + .ops = &cs40l50_dai_ops,
> + },
> +};
> +
> +static int cs40l50_codec_probe(struct snd_soc_component *component)
> +{
> + struct cs40l50_codec *codec = snd_soc_component_get_drvdata(component);
> +
> + codec->bclk_ratio = CS40L50_BCLK_RATIO_DEFAULT;
> +
> + return 0;
> +}
> +
> +static const struct snd_soc_component_driver soc_codec_dev_cs40l50 = {
> + .probe = cs40l50_codec_probe,
> + .dapm_widgets = cs40l50_dapm_widgets,
> + .num_dapm_widgets = ARRAY_SIZE(cs40l50_dapm_widgets),
> + .dapm_routes = cs40l50_dapm_routes,
> + .num_dapm_routes = ARRAY_SIZE(cs40l50_dapm_routes),
> +};
> +
> +static int cs40l50_codec_driver_probe(struct platform_device *pdev)
> +{
> + struct cs40l50 *cs40l50 = dev_get_drvdata(pdev->dev.parent);
> + struct cs40l50_codec *codec;
> +
> + codec = devm_kzalloc(&pdev->dev, sizeof(*codec), GFP_KERNEL);
> + if (!codec)
> + return -ENOMEM;
> +
> + codec->regmap = cs40l50->regmap;
> + codec->dev = &pdev->dev;
> +
> + return devm_snd_soc_register_component(&pdev->dev, &soc_codec_dev_cs40l50,
> + cs40l50_dai, ARRAY_SIZE(cs40l50_dai));
> +}
> +
> +static const struct platform_device_id cs40l50_id[] = {
> + { "cs40l50-codec", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(platform, cs40l50_id);
> +
> +static struct platform_driver cs40l50_codec_driver = {
> + .probe = cs40l50_codec_driver_probe,
> + .id_table = cs40l50_id,
> + .driver = {
> + .name = "cs40l50-codec",
> + },
> +};
> +module_platform_driver(cs40l50_codec_driver);
> +
> +MODULE_DESCRIPTION("ASoC CS40L50 driver");
> +MODULE_AUTHOR("James Ogletree <james.ogletree@cirrus.com>");
> +MODULE_LICENSE("GPL");
> --
> 2.25.1
>
Bottom posting this time.
Hi Mark,
This file has not had any feedback yet for this version. For the sake of efficiency, I
would appreciate your review. That way I can make any needed changes
in the already-planned v11.
Best,
James
^ permalink raw reply
* Re: [PATCH 1/2] HID: intel-ish-hid: fix cache management mistake
From: srinivas pandruvada @ 2024-05-29 22:25 UTC (permalink / raw)
To: Arnd Bergmann, Lixu Zhang, Arnd Bergmann, Jiri Kosina,
Benjamin Tissoires
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <fcbdc4a5-abee-4de8-9fe8-c8486195b96d@app.fastmail.com>
On Wed, 2024-05-29 at 09:06 +0200, Arnd Bergmann wrote:
> On Wed, May 29, 2024, at 08:46, Zhang, Lixu wrote:
> > >
> > > -#include <linux/cacheflush.h>
> > > #include <linux/container_of.h>
> > > #include <linux/dev_printk.h>
> > > #include <linux/dma-mapping.h>
> > > @@ -175,10 +174,11 @@ static int prepare_dma_bufs(struct
> > > ishtp_device
> > > *dev,
> > > return -ENOMEM;
> > >
> > > fragment->fragment_tbl[i].ddr_adrs =
> > > cpu_to_le64(dma_addr);
> > > +
> > > + memcpy(dma_bufs[i], ish_fw->data + offset,
> > > fragment-
> > > > fragment_tbl[i].length);
> > fragment->fragment_tbl[i].length was used before assignment.
> >
> > > + dma_wmb();
> > I tested it on the platform, but it didn't wok.
> >
>
> What behavior do you see instead? If the manual cache
> flush works around a bug, that would indicate that the
> device itself is not coherent and the dma_alloc_coherent()
> in the architecture is broken.
Lixu,
What happens if you remove manual cache flush in your code?
It is possible that boot loader at this time not ready to do fully
coherent ops.
Thanks,
Srinivas
>
> Arnd
^ permalink raw reply
* Re: [PATCH] Adding quirks for 2024 HP Spectre x360 touchpads
From: Aseda Aboagye @ 2024-05-29 22:29 UTC (permalink / raw)
To: Jon Moeller; +Cc: linux-input
In-Reply-To: <CABWf9sbtpJMCPrHRu1jtL7d_ozPmyXO11QedXuTww3nAyzP0vA@mail.gmail.com>
On Tue, May 28, 2024 at 11:21:10AM -0700, Jon Moeller wrote:
> Is there anything special I need to do to get this merged? I was
> hoping this would get worked into 6.10.
I think at a minimum, you need to include some description as to what
problem your patch is trying to solve as part of your commit.
Additionally, you probably want to find the relevant maintainers for the
files that you are modifying and add them to the "To:" field. This
information can be found in the MAINTAINERS file, or you may use the
`get_maintainer.pl` script. It's possible that they may have missed it,
or perhaps are just busy.
https://docs.kernel.org/process/submitting-patches.html may also be of
some help navigating through the submission process.
--
Aseda Aboagye
> On Mon, Apr 29, 2024 at 12:09 AM Jon Moeller <jon@moeller.io> wrote:
> >
> > ---
> > drivers/hid/hid-multitouch.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
^ permalink raw reply
* Re: [PATCH V1 5/5] Add support for Awinic sar sensor.
From: kernel test robot @ 2024-05-29 22:49 UTC (permalink / raw)
To: wangshuaijie, dmitry.torokhov, robh, krzk+dt, conor+dt, jeff,
linux-input, devicetree, linux-kernel
Cc: oe-kbuild-all, wangshuaijie, liweilei, kangjiajun
In-Reply-To: <20240529130608.783624-6-wangshuaijie@awinic.com>
Hi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on e0cce98fe279b64f4a7d81b7f5c3a23d80b92fbc]
url: https://github.com/intel-lab-lkp/linux/commits/wangshuaijie-awinic-com/dt-bindings-input-Add-YAML-to-Awinic-sar-sensor/20240529-211303
base: e0cce98fe279b64f4a7d81b7f5c3a23d80b92fbc
patch link: https://lore.kernel.org/r/20240529130608.783624-6-wangshuaijie%40awinic.com
patch subject: [PATCH V1 5/5] Add support for Awinic sar sensor.
config: riscv-randconfig-r071-20240530 (https://download.01.org/0day-ci/archive/20240530/202405300600.3YW7nPfV-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240530/202405300600.3YW7nPfV-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405300600.3YW7nPfV-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c:489:28: warning: conflicting types for 'aw_parse_bin_header_1_0_0' due to enum/integer mismatch; have 'enum aw_bin_err_val(struct aw_bin *)' [-Wenum-int-mismatch]
489 | static enum aw_bin_err_val aw_parse_bin_header_1_0_0(struct aw_bin *bin)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c:234:12: note: previous declaration of 'aw_parse_bin_header_1_0_0' with type 'int(struct aw_bin *)'
234 | static int aw_parse_bin_header_1_0_0(struct aw_bin *bin);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
--
>> drivers/input/misc/aw_sar/./aw9610x/aw9610x.c:166:9: warning: no previous prototype for 'aw9610x_check_chipid' [-Wmissing-prototypes]
166 | int32_t aw9610x_check_chipid(void *data)
| ^~~~~~~~~~~~~~~~~~~~
>> drivers/input/misc/aw_sar/./aw9610x/aw9610x.c:863:9: warning: no previous prototype for 'aw9610x_init' [-Wmissing-prototypes]
863 | int32_t aw9610x_init(struct aw_sar *p_sar)
| ^~~~~~~~~~~~
>> drivers/input/misc/aw_sar/./aw9610x/aw9610x.c:880:6: warning: no previous prototype for 'aw9610x_deinit' [-Wmissing-prototypes]
880 | void aw9610x_deinit(struct aw_sar *p_sar)
| ^~~~~~~~~~~~~~
--
drivers/input/misc/aw_sar/./aw963xx/aw963xx.c: In function 'aw963xx_irq_handle_func':
>> drivers/input/misc/aw_sar/./aw963xx/aw963xx.c:309:17: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
309 | int32_t ret;
| ^~~
drivers/input/misc/aw_sar/./aw963xx/aw963xx.c: At top level:
>> drivers/input/misc/aw_sar/./aw963xx/aw963xx.c:602:9: warning: no previous prototype for 'aw963xx_check_chipid' [-Wmissing-prototypes]
602 | int32_t aw963xx_check_chipid(void *data)
| ^~~~~~~~~~~~~~~~~~~~
>> drivers/input/misc/aw_sar/./aw963xx/aw963xx.c:955:9: warning: no previous prototype for 'aw963xx_init' [-Wmissing-prototypes]
955 | int32_t aw963xx_init(struct aw_sar *p_sar)
| ^~~~~~~~~~~~
drivers/input/misc/aw_sar/./aw963xx/aw963xx.c: In function 'aw963xx_init':
>> drivers/input/misc/aw_sar/./aw963xx/aw963xx.c:957:25: warning: variable 'aw963xx' set but not used [-Wunused-but-set-variable]
957 | struct aw963xx *aw963xx;
| ^~~~~~~
drivers/input/misc/aw_sar/./aw963xx/aw963xx.c: At top level:
>> drivers/input/misc/aw_sar/./aw963xx/aw963xx.c:974:6: warning: no previous prototype for 'aw963xx_deinit' [-Wmissing-prototypes]
974 | void aw963xx_deinit(struct aw_sar *p_sar)
| ^~~~~~~~~~~~~~
drivers/input/misc/aw_sar/./aw963xx/aw963xx.c: In function 'aw963xx_deinit':
drivers/input/misc/aw_sar/./aw963xx/aw963xx.c:976:25: warning: variable 'aw963xx' set but not used [-Wunused-but-set-variable]
976 | struct aw963xx *aw963xx;
| ^~~~~~~
--
>> drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c:39: warning: Cannot understand * @brief Read register interface
on line 39 - I thought it was a doc line
>> drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c:80: warning: Cannot understand * @brief write register interface
on line 80 - I thought it was a doc line
>> drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c:125: warning: Cannot understand * @brief Write the corresponding bit of the register
on line 125 - I thought it was a doc line
>> drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c:147: warning: Cannot understand * @brief Continuously write data to the chip
on line 147 - I thought it was a doc line
>> drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c:177: warning: Cannot understand * @brief Continuously Read data from chip
on line 177 - I thought it was a doc line
>> drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c:237: warning: Cannot understand *
on line 237 - I thought it was a doc line
>> drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c:544: warning: Cannot understand * @brief Parse bin file
on line 544 - I thought it was a doc line
>> drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c:599: warning: Cannot understand * @brief Calculate the second power
on line 599 - I thought it was a doc line
drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c:620: warning: Cannot understand * @brief Calculate the second power
on line 620 - I thought it was a doc line
--
>> drivers/input/misc/aw_sar/./aw963xx/aw963xx.c:66: warning: Cannot understand * @brief |----------------code ram-----------------|
on line 66 - I thought it was a doc line
--
>> drivers/input/misc/aw_sar/aw_sar.c:1647: warning: Cannot understand * @brief sar sensor initialization logic.
on line 1647 - I thought it was a doc line
>> drivers/input/misc/aw_sar/aw_sar.c:1750: warning: Cannot understand * @brief Distinguish different chips by chip name and obtain relevant chip information
on line 1750 - I thought it was a doc line
>> drivers/input/misc/aw_sar/aw_sar.c:1825: warning: Cannot understand * @brief Drive logic entry
on line 1825 - I thought it was a doc line
vim +489 drivers/input/misc/aw_sar/./comm/aw_sar_comm_interface.c
b01a8a3a3fadc9 shuaijie wang 2024-05-29 477
b01a8a3a3fadc9 shuaijie wang 2024-05-29 478 /********************************************************
b01a8a3a3fadc9 shuaijie wang 2024-05-29 479 *
b01a8a3a3fadc9 shuaijie wang 2024-05-29 480 * If the bin framework header version is 1.0.0,
b01a8a3a3fadc9 shuaijie wang 2024-05-29 481 * determine the data type of bin, and then perform different processing
b01a8a3a3fadc9 shuaijie wang 2024-05-29 482 * according to the data type
b01a8a3a3fadc9 shuaijie wang 2024-05-29 483 * If it is a single bin data type, write the data directly into the structure array
b01a8a3a3fadc9 shuaijie wang 2024-05-29 484 * If it is a multi-bin data type, first obtain the number of bins,
b01a8a3a3fadc9 shuaijie wang 2024-05-29 485 * and then recursively call the bin frame header processing function
b01a8a3a3fadc9 shuaijie wang 2024-05-29 486 * according to the bin number to process the frame header information of each bin separately
b01a8a3a3fadc9 shuaijie wang 2024-05-29 487 *
b01a8a3a3fadc9 shuaijie wang 2024-05-29 488 ********************************************************/
b01a8a3a3fadc9 shuaijie wang 2024-05-29 @489 static enum aw_bin_err_val aw_parse_bin_header_1_0_0(struct aw_bin *bin)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 490 {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 491 unsigned int bin_data_type;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 492 enum aw_bin_err_val ret;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 493
b01a8a3a3fadc9 shuaijie wang 2024-05-29 494 bin_data_type = AW_SAR_GET_32_DATA(*(bin->p_addr + 11),
b01a8a3a3fadc9 shuaijie wang 2024-05-29 495 *(bin->p_addr + 10),
b01a8a3a3fadc9 shuaijie wang 2024-05-29 496 *(bin->p_addr + 9), *(bin->p_addr + 8));
b01a8a3a3fadc9 shuaijie wang 2024-05-29 497 switch (bin_data_type) {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 498 case DATA_TYPE_REGISTER:
b01a8a3a3fadc9 shuaijie wang 2024-05-29 499 case DATA_TYPE_DSP_REG:
b01a8a3a3fadc9 shuaijie wang 2024-05-29 500 case DATA_TYPE_SOC_APP:
b01a8a3a3fadc9 shuaijie wang 2024-05-29 501 // Divided into two processing methods,
b01a8a3a3fadc9 shuaijie wang 2024-05-29 502 // one is single bin processing,
b01a8a3a3fadc9 shuaijie wang 2024-05-29 503 // and the other is single bin processing in multi bin
b01a8a3a3fadc9 shuaijie wang 2024-05-29 504 bin->single_bin_parse_num += 1;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 505 if (!bin->multi_bin_parse_num)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 506 bin->header_info[bin->all_bin_parse_num].valid_data_addr = 60;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 507 aw_get_single_bin_header_1_0_0(bin);
b01a8a3a3fadc9 shuaijie wang 2024-05-29 508 break;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 509 case DATA_TYPE_MULTI_BINS:
b01a8a3a3fadc9 shuaijie wang 2024-05-29 510 /* Get the number of times to enter multi bins */
b01a8a3a3fadc9 shuaijie wang 2024-05-29 511 bin->multi_bin_parse_num += 1;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 512 ret = aw_get_multi_bin_header_1_0_0(bin);
b01a8a3a3fadc9 shuaijie wang 2024-05-29 513 if (ret < 0)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 514 return ret;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 515 break;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 516 default:
b01a8a3a3fadc9 shuaijie wang 2024-05-29 517 return AW_BIN_ERROR_DATA_TYPE;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 518 }
b01a8a3a3fadc9 shuaijie wang 2024-05-29 519 return AW_BIN_ERROR_NONE;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 520 }
b01a8a3a3fadc9 shuaijie wang 2024-05-29 521
b01a8a3a3fadc9 shuaijie wang 2024-05-29 522 /* get the bin's header version */
b01a8a3a3fadc9 shuaijie wang 2024-05-29 523 static enum aw_bin_err_val aw_check_bin_header_version(struct aw_bin *bin)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 524 {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 525 unsigned int header_version;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 526 enum aw_bin_err_val ret;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 527
b01a8a3a3fadc9 shuaijie wang 2024-05-29 528 header_version = AW_SAR_GET_32_DATA(*(bin->p_addr + 7), *(bin->p_addr + 6),
b01a8a3a3fadc9 shuaijie wang 2024-05-29 529 *(bin->p_addr + 5), *(bin->p_addr + 4));
b01a8a3a3fadc9 shuaijie wang 2024-05-29 530
b01a8a3a3fadc9 shuaijie wang 2024-05-29 531
b01a8a3a3fadc9 shuaijie wang 2024-05-29 532 // Write data to the corresponding structure array
b01a8a3a3fadc9 shuaijie wang 2024-05-29 533 // according to different formats of the bin frame header version
b01a8a3a3fadc9 shuaijie wang 2024-05-29 534 switch (header_version) {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 535 case HEADER_VERSION_1_0_0:
b01a8a3a3fadc9 shuaijie wang 2024-05-29 536 ret = aw_parse_bin_header_1_0_0(bin);
b01a8a3a3fadc9 shuaijie wang 2024-05-29 537 return ret;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 538 default:
b01a8a3a3fadc9 shuaijie wang 2024-05-29 539 return AW_BIN_ERROR_HEADER_VERSION;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 540 }
b01a8a3a3fadc9 shuaijie wang 2024-05-29 541 }
b01a8a3a3fadc9 shuaijie wang 2024-05-29 542
b01a8a3a3fadc9 shuaijie wang 2024-05-29 543 /**
b01a8a3a3fadc9 shuaijie wang 2024-05-29 @544 * @brief Parse bin file
b01a8a3a3fadc9 shuaijie wang 2024-05-29 545 *
b01a8a3a3fadc9 shuaijie wang 2024-05-29 546 * @param bin: Store the contents of the parsed bin file
b01a8a3a3fadc9 shuaijie wang 2024-05-29 547 * @return 0 if init succeeded, other if error
b01a8a3a3fadc9 shuaijie wang 2024-05-29 548 */
b01a8a3a3fadc9 shuaijie wang 2024-05-29 549 enum aw_bin_err_val aw_sar_parsing_bin_file(struct aw_bin *bin)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 550 {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 551 enum aw_bin_err_val ret;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 552 int i;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 553
b01a8a3a3fadc9 shuaijie wang 2024-05-29 554 if (!bin)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 555 return AW_BIN_ERROR_NULL_POINT;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 556 bin->p_addr = bin->info.data;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 557 bin->all_bin_parse_num = 0;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 558 bin->multi_bin_parse_num = 0;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 559 bin->single_bin_parse_num = 0;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 560
b01a8a3a3fadc9 shuaijie wang 2024-05-29 561 /* filling bins header info */
b01a8a3a3fadc9 shuaijie wang 2024-05-29 562 ret = aw_check_bin_header_version(bin);
b01a8a3a3fadc9 shuaijie wang 2024-05-29 563 if (ret < 0)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 564 return ret;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 565 bin->p_addr = NULL;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 566
b01a8a3a3fadc9 shuaijie wang 2024-05-29 567 /* check bin header info */
b01a8a3a3fadc9 shuaijie wang 2024-05-29 568 for (i = 0; i < bin->all_bin_parse_num; i++) {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 569 /* check sum */
b01a8a3a3fadc9 shuaijie wang 2024-05-29 570 ret = aw_check_sum(bin, i);
b01a8a3a3fadc9 shuaijie wang 2024-05-29 571 if (ret < 0)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 572 return ret;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 573
b01a8a3a3fadc9 shuaijie wang 2024-05-29 574 /* check register num */
b01a8a3a3fadc9 shuaijie wang 2024-05-29 575 if (bin->header_info[i].bin_data_type == DATA_TYPE_REGISTER) {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 576 ret = aw_check_register_num_v1(bin, i);
b01a8a3a3fadc9 shuaijie wang 2024-05-29 577 if (ret < 0)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 578 return ret;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 579 /* check dsp reg num */
b01a8a3a3fadc9 shuaijie wang 2024-05-29 580 } else if (bin->header_info[i].bin_data_type == DATA_TYPE_DSP_REG) {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 581 ret = aw_check_dsp_reg_num_v1(bin, i);
b01a8a3a3fadc9 shuaijie wang 2024-05-29 582 if (ret < 0)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 583 return ret;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 584 /* check soc app num */
b01a8a3a3fadc9 shuaijie wang 2024-05-29 585 } else if (bin->header_info[i].bin_data_type == DATA_TYPE_SOC_APP) {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 586 ret = aw_check_soc_app_num_v1(bin, i);
b01a8a3a3fadc9 shuaijie wang 2024-05-29 587 if (ret < 0)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 588 return ret;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 589 } else {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 590 bin->header_info[i].valid_data_len = bin->header_info[i].bin_data_len;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 591 }
b01a8a3a3fadc9 shuaijie wang 2024-05-29 592 }
b01a8a3a3fadc9 shuaijie wang 2024-05-29 593
b01a8a3a3fadc9 shuaijie wang 2024-05-29 594 return AW_BIN_ERROR_NONE;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 595 }
b01a8a3a3fadc9 shuaijie wang 2024-05-29 596 /*********************************Parse bin file code end************************************/
b01a8a3a3fadc9 shuaijie wang 2024-05-29 597
b01a8a3a3fadc9 shuaijie wang 2024-05-29 598 /**
b01a8a3a3fadc9 shuaijie wang 2024-05-29 @599 * @brief Calculate the second power
b01a8a3a3fadc9 shuaijie wang 2024-05-29 600 *
b01a8a3a3fadc9 shuaijie wang 2024-05-29 601 * @param cnt: ifrequency
b01a8a3a3fadc9 shuaijie wang 2024-05-29 602 * @return the second power
b01a8a3a3fadc9 shuaijie wang 2024-05-29 603 */
b01a8a3a3fadc9 shuaijie wang 2024-05-29 604 uint32_t aw_sar_pow2(uint32_t cnt)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 605 {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 606 uint32_t sum = 1;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 607 uint32_t i;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 608
b01a8a3a3fadc9 shuaijie wang 2024-05-29 609 if (cnt == 0) {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 610 sum = 1;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 611 } else {
b01a8a3a3fadc9 shuaijie wang 2024-05-29 612 for (i = 0; i < cnt; i++)
b01a8a3a3fadc9 shuaijie wang 2024-05-29 613 sum *= 2;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 614 }
b01a8a3a3fadc9 shuaijie wang 2024-05-29 615
b01a8a3a3fadc9 shuaijie wang 2024-05-29 616 return sum;
b01a8a3a3fadc9 shuaijie wang 2024-05-29 617 }
b01a8a3a3fadc9 shuaijie wang 2024-05-29 618
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 3/5] input: himax_hx83112b: implement MCU register reading
From: Felix Kaechele @ 2024-05-29 23:07 UTC (permalink / raw)
To: Mark Brown, Dmitry Torokhov
Cc: Job Noorman, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <afab9026-e843-4cc4-8733-f45e9ab34276@kaechele.ca>
On 2024-05-14 10:01, Felix Kaechele wrote:
> On 2024-05-14 05:46, Mark Brown wrote:
>> On Mon, May 13, 2024 at 04:01:59PM -0700, Dmitry Torokhov wrote:
>>> On Sat, May 11, 2024 at 08:12:24AM -0400, Felix Kaechele wrote:
>>>> Implement reading from the MCU in a more universal fashion. This allows
>>>> properly handling reads of more than 4 bytes using the AHB FIFO
>>>> implemented in the chip.
>>
>>> Mark, do we have anything in regmap to support this better or having a
>>> wrapper is the best solution here?
>>
>> No, I've not seen something that explicitly requires toggling a burst
>> mode on and off to do a bulk operation. Off the top of my head I'd
>> suggest just always leaving the burst mode enabled but I assume there's
>> some downside to doing that. We could add something but I'm not sure if
>> it's worth it without having seen any other devices with the same need.
>
> I can experiment some more with just leaving burst mode enabled.
I've done some testing now and can confirm that, unfortunately, not
enabling burst mode for every read of the FIFO register results in
unreliable touchscreen operation.
For testing purposes I only enabled burst mode once at both probe and
resume.
The touchscreen will stop working both randomly in normal operation and
reproducibly after returning from screen blanking.
My wild guess is that DSI commands (e.g. for re-initializing the panel)
alter the state of the IC such that the burst mode on the I2C interface
ends up disabled again.
That means the bus read function from this current v2 series could be
used as-is.
I have a v3 in the pipeline to address the comments Conor made on
another patch in the series.
So far those are the only changes compared to this v2. If you have any
other ideas for what I could test in regards to this, please let me
know. Otherwise I'll be sending v3 in the next few days.
Regards,
Felix
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 6f47c7ae8c7afaf9ad291d39f0d3974f191a7946
From: kernel test robot @ 2024-05-30 0:29 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 6f47c7ae8c7afaf9ad291d39f0d3974f191a7946 Merge tag 'v6.9' into next
elapsed time: 1452m
configs tested: 230
configs skipped: 6
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc axs101_defconfig gcc
arc defconfig gcc
arc haps_hs_defconfig gcc
arc nsim_700_defconfig gcc
arc nsimosci_defconfig gcc
arc randconfig-001-20240529 gcc
arc randconfig-001-20240530 gcc
arc randconfig-002-20240529 gcc
arc randconfig-002-20240530 gcc
arc tb10x_defconfig gcc
arm allmodconfig gcc
arm allnoconfig clang
arm allyesconfig gcc
arm bcm2835_defconfig clang
arm defconfig clang
arm hisi_defconfig gcc
arm netwinder_defconfig gcc
arm randconfig-001-20240529 gcc
arm randconfig-002-20240529 gcc
arm randconfig-002-20240530 gcc
arm randconfig-003-20240529 gcc
arm randconfig-004-20240529 gcc
arm randconfig-004-20240530 gcc
arm spear3xx_defconfig clang
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240529 clang
arm64 randconfig-002-20240529 clang
arm64 randconfig-002-20240530 gcc
arm64 randconfig-003-20240529 gcc
arm64 randconfig-003-20240530 gcc
arm64 randconfig-004-20240529 gcc
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240529 gcc
csky randconfig-001-20240530 gcc
csky randconfig-002-20240529 gcc
csky randconfig-002-20240530 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20240529 clang
hexagon randconfig-002-20240529 clang
i386 allmodconfig gcc
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240529 clang
i386 buildonly-randconfig-002-20240529 gcc
i386 buildonly-randconfig-003-20240529 gcc
i386 buildonly-randconfig-004-20240529 clang
i386 buildonly-randconfig-005-20240529 gcc
i386 buildonly-randconfig-006-20240529 clang
i386 defconfig clang
i386 randconfig-001-20240529 clang
i386 randconfig-002-20240529 gcc
i386 randconfig-003-20240529 gcc
i386 randconfig-004-20240529 gcc
i386 randconfig-005-20240529 clang
i386 randconfig-006-20240529 clang
i386 randconfig-011-20240529 clang
i386 randconfig-012-20240529 clang
i386 randconfig-013-20240529 clang
i386 randconfig-014-20240529 gcc
i386 randconfig-015-20240529 clang
i386 randconfig-016-20240529 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240529 gcc
loongarch randconfig-001-20240530 gcc
loongarch randconfig-002-20240529 gcc
loongarch randconfig-002-20240530 gcc
m68k alldefconfig gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
m68k m5272c3_defconfig gcc
m68k mac_defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig gcc
mips allyesconfig gcc
mips bcm47xx_defconfig clang
mips decstation_64_defconfig gcc
mips loongson1c_defconfig gcc
mips loongson3_defconfig gcc
mips malta_qemu_32r6_defconfig gcc
mips maltasmvp_defconfig gcc
mips rb532_defconfig clang
mips sb1250_swarm_defconfig gcc
mips xway_defconfig clang
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240529 gcc
nios2 randconfig-001-20240530 gcc
nios2 randconfig-002-20240529 gcc
nios2 randconfig-002-20240530 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240529 gcc
parisc randconfig-001-20240530 gcc
parisc randconfig-002-20240529 gcc
parisc randconfig-002-20240530 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc klondike_defconfig gcc
powerpc maple_defconfig clang
powerpc mpc83xx_defconfig clang
powerpc obs600_defconfig clang
powerpc ppa8548_defconfig gcc
powerpc ppc44x_defconfig clang
powerpc randconfig-001-20240529 clang
powerpc randconfig-001-20240530 gcc
powerpc randconfig-002-20240529 clang
powerpc randconfig-003-20240529 clang
powerpc randconfig-003-20240530 gcc
powerpc socrates_defconfig gcc
powerpc64 randconfig-001-20240529 gcc
powerpc64 randconfig-001-20240530 gcc
powerpc64 randconfig-002-20240529 clang
powerpc64 randconfig-003-20240529 clang
riscv allmodconfig clang
riscv allnoconfig gcc
riscv allyesconfig clang
riscv defconfig clang
riscv randconfig-001-20240529 gcc
riscv randconfig-002-20240529 clang
riscv randconfig-002-20240530 gcc
s390 allmodconfig clang
s390 allnoconfig clang
s390 allyesconfig gcc
s390 defconfig clang
s390 randconfig-001-20240529 clang
s390 randconfig-002-20240529 gcc
sh alldefconfig gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh kfr2r09-romimage_defconfig gcc
sh polaris_defconfig gcc
sh randconfig-001-20240529 gcc
sh randconfig-001-20240530 gcc
sh randconfig-002-20240529 gcc
sh randconfig-002-20240530 gcc
sh rts7751r2d1_defconfig gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240529 gcc
sparc64 randconfig-001-20240530 gcc
sparc64 randconfig-002-20240529 gcc
sparc64 randconfig-002-20240530 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig gcc
um defconfig clang
um i386_defconfig gcc
um randconfig-001-20240529 clang
um randconfig-001-20240530 gcc
um randconfig-002-20240529 gcc
um randconfig-002-20240530 gcc
um x86_64_defconfig clang
x86_64 allnoconfig clang
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240529 gcc
x86_64 buildonly-randconfig-002-20240529 clang
x86_64 buildonly-randconfig-003-20240529 clang
x86_64 buildonly-randconfig-003-20240530 gcc
x86_64 buildonly-randconfig-004-20240529 gcc
x86_64 buildonly-randconfig-004-20240530 gcc
x86_64 buildonly-randconfig-005-20240529 clang
x86_64 buildonly-randconfig-006-20240529 gcc
x86_64 buildonly-randconfig-006-20240530 gcc
x86_64 defconfig gcc
x86_64 randconfig-001-20240529 gcc
x86_64 randconfig-002-20240529 clang
x86_64 randconfig-003-20240529 clang
x86_64 randconfig-004-20240529 clang
x86_64 randconfig-005-20240529 gcc
x86_64 randconfig-006-20240529 gcc
x86_64 randconfig-011-20240529 gcc
x86_64 randconfig-012-20240529 gcc
x86_64 randconfig-012-20240530 gcc
x86_64 randconfig-013-20240529 clang
x86_64 randconfig-013-20240530 gcc
x86_64 randconfig-014-20240529 gcc
x86_64 randconfig-014-20240530 gcc
x86_64 randconfig-015-20240529 gcc
x86_64 randconfig-016-20240529 clang
x86_64 randconfig-016-20240530 gcc
x86_64 randconfig-071-20240529 clang
x86_64 randconfig-072-20240529 gcc
x86_64 randconfig-073-20240529 gcc
x86_64 randconfig-074-20240529 clang
x86_64 randconfig-075-20240529 clang
x86_64 randconfig-075-20240530 gcc
x86_64 randconfig-076-20240529 clang
x86_64 randconfig-076-20240530 gcc
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa randconfig-001-20240529 gcc
xtensa randconfig-001-20240530 gcc
xtensa randconfig-002-20240529 gcc
xtensa randconfig-002-20240530 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v10 1/8] x86/vmware: Introduce VMware hypercall API
From: Alexey Makhalov @ 2024-05-30 0:44 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, virtualization, hpa, dave.hansen, mingo, tglx, x86,
netdev, richardcochran, linux-input, dmitry.torokhov, zackr,
linux-graphics-maintainer, pv-drivers, timothym, akaher,
dri-devel, daniel, airlied, tzimmermann, mripard,
maarten.lankhorst, horms, kirill.shutemov
In-Reply-To: <20240527170734.GCZlS91uXD68HRN1na@fat_crate.local>
On 5/27/24 10:07 AM, Borislav Petkov wrote:
> On Thu, May 23, 2024 at 12:14:39PM -0700, Alexey Makhalov wrote:
>> +#define VMWARE_HYPERCALL \
>> + ALTERNATIVE_3("", \
>> + "jmp .Lport_call%=", X86_FEATURE_HYPERVISOR, \
>> + "jmp .Lvmcall%=", X86_FEATURE_VMCALL, \
>> + "vmmcall\n\t" \
>> + "jmp .Lend%=", X86_FEATURE_VMW_VMMCALL) \
>> + "cmpb $" \
>> + __stringify(CPUID_VMWARE_FEATURES_ECX_VMMCALL) \
>> + ", %[mode]\n\t" \
>> + "jg .Lvmcall%=\n\t" \
>> + "je .Lvmmcall%=\n\t" \
>> + ".Lport_call%=: movw %[port], %%dx\n\t" \
>> + "inl (%%dx), %%eax\n\t" \
>> + "jmp .Lend%=\n\t" \
>> + ".Lvmmcall%=: vmmcall\n\t" \
>> + "jmp .Lend%=\n\t" \
>> + ".Lvmcall%=: vmcall\n\t" \
>> + ".Lend%=:"
>
> So applied (and with minor fixups for the proper indentation, see end of
> this mail) this looks like this:
>
> .pushsection .altinstructions,"a"
> .long 661b - .
> .long 6641f - .
> .4byte ( 4*32+31)
> .byte 663b-661b
> .byte 6651f-6641f
> .long 661b - .
> .long 6642f - .
> .4byte ( 8*32+18)
> .byte 663b-661b
> .byte 6652f-6642f
> .long 661b - .
> .long 6643f - .
> .4byte ( 8*32+19)
> .byte 663b-661b
> .byte 6653f-6643f
> .popsection
> .pushsection .altinstr_replacement, "ax"
> # ALT: replacement 1
> 6641:
> jmp .Lport_call72
> 6651:
> # ALT: replacement 2
> 6642:
> jmp .Lvmcall72
> 6652:
> # ALT: replacement 3
> 6643:
> vmmcall
> jmp .Lend72
> 6653:
> .popsection
> cmpb $((((1UL))) << (0)), vmware_hypercall_mode(%rip) # vmware_hypercall_mode
> jg .Lvmcall72
> je .Lvmmcall72
> .Lport_call72:
> movw $22104, %dx #
> inl (%dx), %eax
> jmp .Lend72
> .Lvmmcall72:
> vmmcall
> jmp .Lend72
> .Lvmcall72:
> vmcall
> .Lend72:
>
> ---
>
> so AFAICT, you want three things:
>
> 1. X86_FEATURE_HYPERVISOR - that is always set when running as a guest.
> For that it should do:
>
> movw $22104, %dx #
> inl (%dx), %eax
>
> 2. X86_FEATURE_VMCALL:
>
> vmcall
>
> 3. X86_FEATURE_VMW_VMMCALL:
>
> vmmcall
>
> So why don't you simply do that?
>
> vmware_set_capabilities() sets vmware_hypercall_mode *and* those feature
> flags at the same time.
>
> And you either support VMCALL or VMMCALL so the first thing should be the
> fallback for some ancient crap.
>
> IOW, your hypercall alternative should simply be:
>
> ALTERNATIVE_2("vmcall", "vmmcall", X86_FEATURE_VMW_VMMCALL, "movw %[port], %%dx; "inl (%%dx), %%eax", X86_FEATURE_HYPERVISOR);
>
> without any more silly dance?
While most of the vmware_hypercall callers are executed after
alternative patching applied, there are small amount of hypercalls
running before that.
Only for them we have the logic of analyzing vmware_hypercall_mode as a
default alternative code. And there are 2 constraints:
1. vmcall/vmmcall are not supported by old ESXi/Workstation/Fusion. We
have to use in/out instructions. After the end of support of old
hypervisors the alternative can be simplified as follow:
ALTERNATIVE("vmcall", "vmmcall", X86_FEATURE_VMW_VMMCALL);
2. SEV-ES enabled VMs should use _only_ vmcall/vmmcall as in/out
instructions cause faults.
Another approach that we discussed internally was to use
ALTERNATIVE_2("movw %[port], %%dx; "inl (%%dx), %%eax", "vmcall",
X86_FEATURE_VMW_VMCALL, "vmmcall", X86_FEATURE_VMW_VMMCALL) for
vmware_hypercallX family of functions, _and_ to have a separate API
vmware_sev_hypercallX, with the silly dance without an alternative
inside, to be used only by early boot code, before alternative
application. But, it's error prone when things come to boot time related
code movements or rearrangements as it puts additional requirement for
SEV-ES understanding/testing for VMware guests.
So, we picked a safe solution until a deprecation of port based
hypercalls, which was mentioned above.
See also a commit bac7b4e843232 ("x86/vmware: Update platform detection
code for VMCALL/VMMCALL hypercalls") where silly dance was introduced
with VMWARE_CMD macro.
>
> Hmmm?
>
> ---
>
> Fixup indentation for proper .s output:
>
> diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
> index 5114f4c75c54..8be877d8bb7c 100644
> --- a/arch/x86/include/asm/vmware.h
> +++ b/arch/x86/include/asm/vmware.h
> @@ -70,17 +70,18 @@ extern u8 vmware_hypercall_mode;
> "jmp .Lvmcall%=", X86_FEATURE_VMCALL, \
> "vmmcall\n\t" \
> "jmp .Lend%=", X86_FEATURE_VMW_VMMCALL) \
> - "cmpb $" \
> - __stringify(CPUID_VMWARE_FEATURES_ECX_VMMCALL) \
> - ", %[mode]\n\t" \
> + "\tcmpb $" __stringify(CPUID_VMWARE_FEATURES_ECX_VMMCALL) ", %[mode]\n\t" \
Noted \t prefix before cmpb, but will keep original 3 lines to fit in 80
columns limit.
> "jg .Lvmcall%=\n\t" \
> - "je .Lvmmcall%=\n\t" \
> - ".Lport_call%=: movw %[port], %%dx\n\t" \
> + "je .Lvmmcall%=\n" \
> + ".Lport_call%=:\n\t" \
> + "movw %[port], %%dx\n\t" \
Noted having labels on a separate line.
> "inl (%%dx), %%eax\n\t" \
> - "jmp .Lend%=\n\t" \
> - ".Lvmmcall%=: vmmcall\n\t" \
> - "jmp .Lend%=\n\t" \
> - ".Lvmcall%=: vmcall\n\t" \
> + "jmp .Lend%=\n" \
> + ".Lvmmcall%=:\n\t" \
> + "vmmcall\n\t" \
> + "jmp .Lend%=\n" \
> + ".Lvmcall%=:\n\t" \
> + "vmcall\n" \
> ".Lend%=:"
>
> static inline
>
>
Best regards,
--Alexey
^ permalink raw reply
* Re: [PATCH v10 6/8] x86/vmware: Correct macro names
From: Alexey Makhalov @ 2024-05-30 0:45 UTC (permalink / raw)
To: Markus Elfring, linux-graphics-maintainer, pv-drivers,
virtualization, dri-devel, linux-input, netdev, kernel-janitors,
x86, Borislav Petkov, Dave Hansen, H. Peter Anvin, Ingo Molnar,
Thomas Gleixner
Cc: LKML, Ajay Kaher, Dmitry Torokhov, Daniel Vetter, David Airlie,
Kirill A. Shutemov, Maarten Lankhorst, Maxime Ripard,
Simon Horman, Thomas Zimmermann, Tim Merrifield, Zack Rusin
In-Reply-To: <448230a6-1afd-416f-a430-3fc83d81908f@web.de>
On 5/25/24 8:53 AM, Markus Elfring wrote:
>> VCPU_RESERVED and LEGACY_X2APIC are not VMware hypercall commands.
>> These are bits in return value of VMWARE_CMD_GETVCPU_INFO command.
>> Change VMWARE_CMD_ prefix to GETVCPU_INFO_ one. …
>
> Can such information be relevant for the addition of the tag “Fixes”?
>
Makes sense! Thanks, --Alexey
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS a69ce592cbe0417664bc5a075205aa75c2ec1273
From: kernel test robot @ 2024-05-30 0:54 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: a69ce592cbe0417664bc5a075205aa75c2ec1273 Input: elantech - fix touchpad state on resume for Lenovo N24
elapsed time: 1477m
configs tested: 209
configs skipped: 7
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240529 gcc
arc randconfig-001-20240530 gcc
arc randconfig-002-20240529 gcc
arc randconfig-002-20240530 gcc
arm allmodconfig gcc
arm allnoconfig clang
arm allyesconfig gcc
arm defconfig clang
arm moxart_defconfig gcc
arm randconfig-001-20240529 gcc
arm randconfig-002-20240529 gcc
arm randconfig-002-20240530 gcc
arm randconfig-003-20240529 gcc
arm randconfig-004-20240529 gcc
arm randconfig-004-20240530 gcc
arm rpc_defconfig clang
arm spear13xx_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240529 clang
arm64 randconfig-002-20240529 clang
arm64 randconfig-002-20240530 gcc
arm64 randconfig-003-20240529 gcc
arm64 randconfig-003-20240530 gcc
arm64 randconfig-004-20240529 gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240529 gcc
csky randconfig-001-20240530 gcc
csky randconfig-002-20240529 gcc
csky randconfig-002-20240530 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20240529 clang
hexagon randconfig-002-20240529 clang
i386 allmodconfig gcc
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240529 clang
i386 buildonly-randconfig-002-20240529 gcc
i386 buildonly-randconfig-003-20240529 gcc
i386 buildonly-randconfig-004-20240529 clang
i386 buildonly-randconfig-005-20240529 gcc
i386 buildonly-randconfig-006-20240529 clang
i386 defconfig clang
i386 randconfig-001-20240529 clang
i386 randconfig-002-20240529 gcc
i386 randconfig-003-20240529 gcc
i386 randconfig-004-20240529 gcc
i386 randconfig-005-20240529 clang
i386 randconfig-006-20240529 clang
i386 randconfig-011-20240529 clang
i386 randconfig-012-20240529 clang
i386 randconfig-013-20240529 clang
i386 randconfig-014-20240529 gcc
i386 randconfig-015-20240529 clang
i386 randconfig-016-20240529 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240529 gcc
loongarch randconfig-001-20240530 gcc
loongarch randconfig-002-20240529 gcc
loongarch randconfig-002-20240530 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig gcc
mips allyesconfig gcc
mips fuloong2e_defconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240529 gcc
nios2 randconfig-001-20240530 gcc
nios2 randconfig-002-20240529 gcc
nios2 randconfig-002-20240530 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
openrisc or1ksim_defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240529 gcc
parisc randconfig-001-20240530 gcc
parisc randconfig-002-20240529 gcc
parisc randconfig-002-20240530 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc linkstation_defconfig clang
powerpc lite5200b_defconfig clang
powerpc randconfig-001-20240529 clang
powerpc randconfig-001-20240530 gcc
powerpc randconfig-002-20240529 clang
powerpc randconfig-003-20240529 clang
powerpc randconfig-003-20240530 gcc
powerpc64 randconfig-001-20240529 gcc
powerpc64 randconfig-001-20240530 gcc
powerpc64 randconfig-002-20240529 clang
powerpc64 randconfig-003-20240529 clang
riscv allnoconfig gcc
riscv defconfig clang
riscv nommu_virt_defconfig clang
riscv randconfig-001-20240529 gcc
riscv randconfig-002-20240529 clang
riscv randconfig-002-20240530 gcc
riscv rv32_defconfig clang
s390 allmodconfig clang
s390 allnoconfig clang
s390 allyesconfig gcc
s390 defconfig clang
s390 randconfig-001-20240529 clang
s390 randconfig-002-20240529 gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh ecovec24_defconfig gcc
sh randconfig-001-20240529 gcc
sh randconfig-001-20240530 gcc
sh randconfig-002-20240529 gcc
sh randconfig-002-20240530 gcc
sh rsk7269_defconfig gcc
sh se7712_defconfig gcc
sh se7750_defconfig gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240529 gcc
sparc64 randconfig-001-20240530 gcc
sparc64 randconfig-002-20240529 gcc
sparc64 randconfig-002-20240530 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig gcc
um defconfig clang
um i386_defconfig gcc
um randconfig-001-20240529 clang
um randconfig-001-20240530 gcc
um randconfig-002-20240529 gcc
um randconfig-002-20240530 gcc
um x86_64_defconfig clang
x86_64 allnoconfig clang
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240529 gcc
x86_64 buildonly-randconfig-002-20240529 clang
x86_64 buildonly-randconfig-003-20240529 clang
x86_64 buildonly-randconfig-003-20240530 gcc
x86_64 buildonly-randconfig-004-20240529 gcc
x86_64 buildonly-randconfig-004-20240530 gcc
x86_64 buildonly-randconfig-005-20240529 clang
x86_64 buildonly-randconfig-006-20240529 gcc
x86_64 buildonly-randconfig-006-20240530 gcc
x86_64 defconfig gcc
x86_64 randconfig-001-20240529 gcc
x86_64 randconfig-002-20240529 clang
x86_64 randconfig-003-20240529 clang
x86_64 randconfig-004-20240529 clang
x86_64 randconfig-005-20240529 gcc
x86_64 randconfig-006-20240529 gcc
x86_64 randconfig-011-20240529 gcc
x86_64 randconfig-012-20240529 gcc
x86_64 randconfig-012-20240530 gcc
x86_64 randconfig-013-20240529 clang
x86_64 randconfig-013-20240530 gcc
x86_64 randconfig-014-20240529 gcc
x86_64 randconfig-014-20240530 gcc
x86_64 randconfig-015-20240529 gcc
x86_64 randconfig-016-20240529 clang
x86_64 randconfig-016-20240530 gcc
x86_64 randconfig-071-20240529 clang
x86_64 randconfig-072-20240529 gcc
x86_64 randconfig-073-20240529 gcc
x86_64 randconfig-074-20240529 clang
x86_64 randconfig-075-20240529 clang
x86_64 randconfig-075-20240530 gcc
x86_64 randconfig-076-20240530 gcc
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa cadence_csp_defconfig gcc
xtensa nommu_kc705_defconfig gcc
xtensa randconfig-001-20240529 gcc
xtensa randconfig-001-20240530 gcc
xtensa randconfig-002-20240529 gcc
xtensa randconfig-002-20240530 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH V1 5/5] Add support for Awinic sar sensor.
From: kernel test robot @ 2024-05-30 4:27 UTC (permalink / raw)
To: wangshuaijie, dmitry.torokhov, robh, krzk+dt, conor+dt, jeff,
linux-input, devicetree, linux-kernel
Cc: oe-kbuild-all, wangshuaijie, liweilei, kangjiajun
In-Reply-To: <20240529130608.783624-6-wangshuaijie@awinic.com>
Hi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on e0cce98fe279b64f4a7d81b7f5c3a23d80b92fbc]
url: https://github.com/intel-lab-lkp/linux/commits/wangshuaijie-awinic-com/dt-bindings-input-Add-YAML-to-Awinic-sar-sensor/20240529-211303
base: e0cce98fe279b64f4a7d81b7f5c3a23d80b92fbc
patch link: https://lore.kernel.org/r/20240529130608.783624-6-wangshuaijie%40awinic.com
patch subject: [PATCH V1 5/5] Add support for Awinic sar sensor.
config: xtensa-randconfig-r064-20240530 (https://download.01.org/0day-ci/archive/20240530/202405301244.1ZqAu1Pf-lkp@intel.com/config)
compiler: xtensa-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240530/202405301244.1ZqAu1Pf-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405301244.1ZqAu1Pf-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/input/misc/aw_sar/aw_sar.c:1992:34: warning: 'aw_sar_dt_match' defined but not used [-Wunused-const-variable=]
1992 | static const struct of_device_id aw_sar_dt_match[] = {
| ^~~~~~~~~~~~~~~
vim +/aw_sar_dt_match +1992 drivers/input/misc/aw_sar/aw_sar.c
1991
> 1992 static const struct of_device_id aw_sar_dt_match[] = {
1993 { .compatible = "awinic,aw96103" },
1994 { .compatible = "awinic,aw96105" },
1995 { .compatible = "awinic,aw96303" },
1996 { .compatible = "awinic,aw96305" },
1997 { .compatible = "awinic,aw96308" },
1998 };
1999
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* RE: [PATCH 1/2] HID: intel-ish-hid: fix cache management mistake
From: Zhang, Lixu @ 2024-05-30 7:41 UTC (permalink / raw)
To: srinivas pandruvada, Arnd Bergmann, Arnd Bergmann, Jiri Kosina,
Benjamin Tissoires, Xu, Even
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <ed3236173ff6fdb1cb6962f388b41e6b90586335.camel@linux.intel.com>
>-----Original Message-----
>From: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
>Sent: Thursday, May 30, 2024 6:25 AM
>To: Arnd Bergmann <arnd@arndb.de>; Zhang, Lixu <lixu.zhang@intel.com>;
>Arnd Bergmann <arnd@kernel.org>; Jiri Kosina <jikos@kernel.org>; Benjamin
>Tissoires <bentiss@kernel.org>
>Cc: linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH 1/2] HID: intel-ish-hid: fix cache management mistake
>
>On Wed, 2024-05-29 at 09:06 +0200, Arnd Bergmann wrote:
>> On Wed, May 29, 2024, at 08:46, Zhang, Lixu wrote:
>> > >
>> >
>> > > + dma_wmb();
>> > I tested it on the platform, but it didn't wok.
>> >
>>
>> What behavior do you see instead?
Hi Arnd, please refer to the information below.
>> If the manual cache flush works
>> around a bug, that would indicate that the device itself is not
>> coherent and the dma_alloc_coherent() in the architecture is broken.
>
>Lixu,
>
>What happens if you remove manual cache flush in your code?
When the driver side sends the next start command, it receives an error response, which is likely because the bootloader failed to verify the firmware image.
Thanks,
Lixu
>It is possible that boot loader at this time not ready to do fully coherent ops.
>
>Thanks,
>Srinivas
>
>> Arnd
^ permalink raw reply
* Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization
From: Dmitry Baryshkov @ 2024-05-30 8:07 UTC (permalink / raw)
To: Limonciello, Mario, Dmitry Torokhov
Cc: Ville Syrjälä, dri-devel, amd-gfx, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
linux-kernel, Chris Bainbridge, hughsient, linux-input
In-Reply-To: <873b7a7b-139d-498e-89da-098cb3d7599d@amd.com>
On Thu, 30 May 2024 at 07:41, Limonciello, Mario
<mario.limonciello@amd.com> wrote:
>
>
> >> Also a direct acpi_lid_open() call seems a bit iffy. But I guess if
> >> someone needs this to work on non-ACPI system they get to figure out
> >> how to abstract it better. acpi_lid_open() does seem to return != 0
> >> when ACPI is not supported, so at least it would err on the side
> >> of enabling everything.
> >
> > Thanks. I was going to comment, but you got it first. I think a proper
> > implementation should check for SW_LID input device instead of simply
> > using acpi_lid_open(). This will handle the issue for other,
> > non-ACPI-based laptops.
> >
>
> Can you suggest how this would actually work? AFAICT the only way to
> discover if input devices support SW_LID would be to iterate all the
> input devices in the kernel and look for whether ->swbit has SW_LID set.
>
> This then turns into a dependency problem of whether any myriad of
> drivers have started to report SW_LID. It's also a state machine
> problem because other drivers can be unloaded at will.
>
> And then what do you if more than one sets SW_LID?
It might be easier to handle this in the input subsystem. For example
by using a refcount-like variable which handles all the LIDs and
counts if all of them are closed. Or if any of the LIDs is closed.
>
> IOW - a lot of complexity for a non-ACPI system. Does such a problem
> exist in non-ACPI systems?
There are non-ACPI laptops. For example Chromebooks. Or Lenovo X13s,
Lenovo Yoga C630, Lenovo Flex5G, etc. We are expecting more to come in
the next few months. And I don't see why they won't have the same
problem.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH RESEND v10 5/5] ASoC: cs40l50: Support I2S streaming to CS40L50
From: Mark Brown @ 2024-05-30 10:05 UTC (permalink / raw)
To: James Ogletree
Cc: James Ogletree, Dmitry Torokhov, robh+dt@kernel.org,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Jeff LaBundy,
open list:CIRRUS LOGIC HAPTIC DRIVERS,
open list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
David Rhodes
In-Reply-To: <61971924-D827-4F35-813A-5807466CBA14@cirrus.com>
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]
On Wed, May 29, 2024 at 10:03:00PM +0000, James Ogletree wrote:
> This file has not had any feedback yet for this version. For the sake of efficiency, I
> would appreciate your review. That way I can make any needed changes
> in the already-planned v11.
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.
Please delete unneeded context from mails when replying. Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.
Please don't ignore review comments, people are generally making them
for a reason and are likely to have the same concerns if issues remain
unaddressed. Having to repeat the same comments can get repetitive and
make people question the value of time spent reviewing. If you disagree
with the review comments that's fine but you need to reply and discuss
your concerns so that the reviewer can understand your decisions.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v10 5/5] ASoC: cs40l50: Support I2S streaming to CS40L50
From: Rivera-Matos, Ricardo @ 2024-05-30 17:07 UTC (permalink / raw)
To: James Ogletree, dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt,
conor+dt, lee, broonie, jeff
Cc: patches, linux-sound, linux-input, devicetree, David Rhodes
In-Reply-To: <20240408153214.42368-6-jogletre@opensource.cirrus.com>
On 4/8/24 10:32 AM, James Ogletree wrote:
> Introduce support for Cirrus Logic Device CS40L50: a
> haptic driver with waveform memory, integrated DSP,
> and closed-loop algorithms.
>
> The ASoC driver enables I2S streaming to the device.
>
> Reviewed-by: David Rhodes <drhodes@opensource.cirrus.com>
> Signed-off-by: James Ogletree <jogletre@opensource.cirrus.com>
> ---
> MAINTAINERS | 1 +
> sound/soc/codecs/Kconfig | 11 ++
> sound/soc/codecs/Makefile | 2 +
> sound/soc/codecs/cs40l50-codec.c | 308 +++++++++++++++++++++++++++++++
> 4 files changed, 322 insertions(+)
> create mode 100644 sound/soc/codecs/cs40l50-codec.c
>
<cut>
> diff --git a/sound/soc/codecs/cs40l50-codec.c b/sound/soc/codecs/cs40l50-codec.c
> new file mode 100644
> index 000000000000..6d4a0970b219
> --- /dev/null
> +++ b/sound/soc/codecs/cs40l50-codec.c
> @@ -0,0 +1,308 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// CS40L50 Advanced Haptic Driver with waveform memory,
> +// integrated DSP, and closed-loop algorithms
> +//
> +// Copyright 2024 Cirrus Logic, Inc.
> +//
> +// Author: James Ogletree <james.ogletree@cirrus.com>
> +
> +#include <linux/bitfield.h>
> +#include <linux/mfd/cs40l50.h>
> +#include <linux/pm_runtime.h>
Is pm_runtime.h being used in the context of the codec driver? If not,
you should drop it.
> +#include <sound/pcm_params.h>
> +#include <sound/soc.h>
> +
<cut>
> +
> +static const struct cs40l50_pll_config cs40l50_pll_cfg[] = {
> + { 32768, 0x00 },
> + { 1536000, 0x1B },
> + { 3072000, 0x21 },
> + { 6144000, 0x28 },
> + { 9600000, 0x30 },
> + { 12288000, 0x33 },
> +};
> +
> +static int cs40l50_get_clk_config(unsigned int freq, unsigned int *cfg)
You could constify freq.
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(cs40l50_pll_cfg); i++) {
> + if (cs40l50_pll_cfg[i].freq == freq) {
> + *cfg = cs40l50_pll_cfg[i].cfg;
> + return 0;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int cs40l50_swap_ext_clk(struct cs40l50_codec *codec, unsigned int clk_src)
You could constify clk_src.
> +{
> + unsigned int cfg;
> + int ret;
> +
> + switch (clk_src) {
> + case CS40L50_PLL_REFCLK_BCLK:
> + ret = cs40l50_get_clk_config(codec->bclk_ratio * codec->rate, &cfg);
> + if (ret)
> + return ret;
> + break;
> + case CS40L50_PLL_REFCLK_MCLK:
> + cfg = CS40L50_PLL_REEFCLK_MCLK_CFG;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + ret = regmap_update_bits(codec->regmap, CS40L50_REFCLK_INPUT,
> + CS40L50_PLL_REFCLK_LOOP_MASK,
> + CS40L50_PLL_REFCLK_OPEN_LOOP <<
> + CS40L50_PLL_REFCLK_LOOP_SHIFT);
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(codec->regmap, CS40L50_REFCLK_INPUT,
> + CS40L50_PLL_REFCLK_FREQ_MASK |
> + CS40L50_PLL_REFCLK_SEL_MASK,
> + (cfg << CS40L50_PLL_REFCLK_FREQ_SHIFT) | clk_src);
> + if (ret)
> + return ret;
> +
> + return regmap_update_bits(codec->regmap, CS40L50_REFCLK_INPUT,
> + CS40L50_PLL_REFCLK_LOOP_MASK,
> + CS40L50_PLL_REFCLK_CLOSED_LOOP <<
> + CS40L50_PLL_REFCLK_LOOP_SHIFT);
> +}
> +
<cut>
> +
> +MODULE_DESCRIPTION("ASoC CS40L50 driver");
> +MODULE_AUTHOR("James Ogletree <james.ogletree@cirrus.com>");
> +MODULE_LICENSE("GPL");
This gets my Reviewed-by pending these edits.
Ricardo
^ permalink raw reply
* Re: [PATCH v3 2/2] input: Add support for "Do Not Disturb"
From: Dmitry Torokhov @ 2024-05-30 20:29 UTC (permalink / raw)
To: Aseda Aboagye; +Cc: Jiri Kosina, Benjamin Tissoires, linux-input
In-Reply-To: <ZldzsCybMzSWnZaQ@google.com>
On Wed, May 29, 2024 at 01:28:00PM -0500, Aseda Aboagye wrote:
> HUTRR94 added support for a new usage titled "System Do Not Disturb"
> which toggles a system-wide Do Not Disturb setting. This commit simply
> adds a new event code for the usage.
>
> Signed-off-by: Aseda Aboagye <aaboagye@chromium.org>
> ---
> Changes from v2:
> - Added underscores to make `KEY_DO_NOT_DISTURB`.
>
> Changes from v1:
> - Modified formatting to match existing code, ignoring checkpatch.pl.
>
> drivers/hid/hid-debug.c | 1 +
> drivers/hid/hid-input.c | 8 ++++++++
> include/uapi/linux/input-event-codes.h | 1 +
> 3 files changed, 10 insertions(+)
>
> diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
> index 7749c81b6227..4ccfbd860bbe 100644
> --- a/drivers/hid/hid-debug.c
> +++ b/drivers/hid/hid-debug.c
> @@ -975,6 +975,7 @@ static const char *keys[KEY_MAX + 1] = {
> [KEY_CAMERA_ACCESS_DISABLE] = "CameraAccessDisable",
> [KEY_CAMERA_ACCESS_TOGGLE] = "CameraAccessToggle",
> [KEY_ACCESSIBILITY] = "Accessibility",
> + [KEY_DO_NOT_DISTURB] = "DoNotDisturb",
> [KEY_DICTATE] = "Dictate",
> [KEY_MICMUTE] = "MicrophoneMute",
> [KEY_BRIGHTNESS_MIN] = "BrightnessMin",
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 1ecc5ad57b56..31feb5e0714f 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -826,6 +826,14 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
> break;
> }
>
> + if ((usage->hid & 0xf0) == 0x90) { /* SystemControl*/
> + switch (usage->hid & 0xf) {
> + case 0xb: map_key_clear(KEY_DO_NOT_DISTURB); break;
> + default: goto ignore;
> + }
> + break;
> + }
> +
> if ((usage->hid & 0xf0) == 0xa0) { /* SystemControl */
> switch (usage->hid & 0xf) {
> case 0x9: map_key_clear(KEY_MICMUTE); break;
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index 7ff6eeef1af0..07038fd9682d 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -618,6 +618,7 @@
> #define KEY_CAMERA_ACCESS_DISABLE 0x24c /* Disables programmatic access to camera devices. (HUTRR72) */
> #define KEY_CAMERA_ACCESS_TOGGLE 0x24d /* Toggles the current state of the camera access control. (HUTRR72) */
> #define KEY_ACCESSIBILITY 0x24e /* Toggles the system bound accessibility UI/command (HUTRR116) */
> +#define KEY_DO_NOT_DISTURB 0x24f /* Toggles the system-wide "Do Not Disturb" control (HUTRR94)*/
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Feel free to merge through HID tree.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization
From: Dmitry Torokhov @ 2024-05-30 20:44 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Limonciello, Mario, Ville Syrjälä, dri-devel, amd-gfx,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, linux-kernel, Chris Bainbridge, hughsient,
linux-input
In-Reply-To: <CAA8EJpqODpGX-RthQ8qu3oU80qXp8a-N1Chz-dcQXjKYoDfEgw@mail.gmail.com>
On Thu, May 30, 2024 at 11:07:53AM +0300, Dmitry Baryshkov wrote:
> On Thu, 30 May 2024 at 07:41, Limonciello, Mario
> <mario.limonciello@amd.com> wrote:
> >
> >
> > >> Also a direct acpi_lid_open() call seems a bit iffy. But I guess if
> > >> someone needs this to work on non-ACPI system they get to figure out
> > >> how to abstract it better. acpi_lid_open() does seem to return != 0
> > >> when ACPI is not supported, so at least it would err on the side
> > >> of enabling everything.
> > >
> > > Thanks. I was going to comment, but you got it first. I think a proper
> > > implementation should check for SW_LID input device instead of simply
> > > using acpi_lid_open(). This will handle the issue for other,
> > > non-ACPI-based laptops.
> > >
> >
> > Can you suggest how this would actually work? AFAICT the only way to
> > discover if input devices support SW_LID would be to iterate all the
> > input devices in the kernel and look for whether ->swbit has SW_LID set.
> >
> > This then turns into a dependency problem of whether any myriad of
> > drivers have started to report SW_LID. It's also a state machine
> > problem because other drivers can be unloaded at will.
> >
> > And then what do you if more than one sets SW_LID?
>
> It might be easier to handle this in the input subsystem. For example
> by using a refcount-like variable which handles all the LIDs and
> counts if all of them are closed. Or if any of the LIDs is closed.
Yes, install an input handler matching on EV_SW/SW_LID so you will get
notified when input devices capable of reporting SW_LID appear and
disappear and also when SW_LID event is being generated, and handle as
you wish. Something like
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/40e9f6a991856ee7d504ac1ccd587e435775cfc4%5E%21/#F0
In practice I think it is pretty safe to assume only 1 lid for a
laptop/device.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: wacom_w8001: Check for string overflow from strscpy calls
From: Dmitry Torokhov @ 2024-05-30 23:48 UTC (permalink / raw)
To: Jason Gerecke
Cc: Ping Cheng, linux-input, Aaron Armstrong Skomra, Joshua Dickens,
Joshua Dickens
In-Reply-To: <CANRwn3SuTjdCCK4YH1ObvsC_gZuythAQ7kSHJP-CiAFw9h5Qcw@mail.gmail.com>
On Thu, May 23, 2024 at 09:51:42AM -0700, Jason Gerecke wrote:
> [...] If you don't like the idea of introducing non-actionable
> warnings, would you be open to a small cleanup patch instead (see
> attached as an example)? There's no particularly good reason to split
> string generation across calls to strscpy and strlcat when a single
> call to snprintf would do, and snprintf is not __must_check on any of
> the kernels we backport to.
Yes, I actually like it much better, applied.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3] Input: goodix-berlin - Add sysfs interface for reading and writing touch IC registers
From: Dmitry Torokhov @ 2024-05-30 23:53 UTC (permalink / raw)
To: Charles Wang
Cc: hadess, hdegoede, neil.armstrong, hughsient, broonie, jeff,
linux-input, linux-kernel
In-Reply-To: <20240514115135.21410-1-charles.goodix@gmail.com>
Hi Charles,
On Tue, May 14, 2024 at 07:44:43PM +0800, Charles Wang wrote:
> +static ssize_t registers_read(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf, loff_t off, size_t count)
> +{
> + struct regmap *regmap;
> + int error;
> +
> + regmap = dev_get_regmap(kobj_to_dev(kobj), NULL);
We already have goodix_berlin_core->regmap, going through drvdata should
be cheaper than scanning devres resources for the regmap data, so I'll
change this.
> + error = regmap_raw_read(regmap, (unsigned int)off,
> + buf, count);
> +
> + return error ? error : count;
> +}
> +
> +static ssize_t registers_write(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf, loff_t off, size_t count)
> +{
> + struct regmap *regmap;
> + int error;
> +
> + regmap = dev_get_regmap(kobj_to_dev(kobj), NULL);
> + error = regmap_raw_write(regmap, (unsigned int)off,
> + buf, count);
> +
> + return error ? error : count;
> +}
> +
> +BIN_ATTR_RW(registers, 0);
I do not think it is a good idea to allow the world read all registers.
Any objection to make it BIN_ATTR_ADMIN_RW()?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/2] Input: silead - Always support 10 fingers
From: Dmitry Torokhov @ 2024-05-30 23:54 UTC (permalink / raw)
To: Hans de Goede
Cc: Ilpo Järvinen, Andy Shevchenko, linux-input,
platform-driver-x86
In-Reply-To: <9103e7ae-70f4-4ca0-a18d-322bdedbbdba@redhat.com>
On Mon, May 27, 2024 at 09:46:54AM +0200, Hans de Goede wrote:
> Hi,
>
> On 5/26/24 6:19 AM, Dmitry Torokhov wrote:
> > On Sat, May 25, 2024 at 09:38:52PM +0200, Hans de Goede wrote:
> >> Hi all,
> >>
> >> The first patch in this series stops making the maximum number of supported
> >> fingers in silead_ts configurable, replacing this with simply hardcoding it
> >> to 10.
> >>
> >> The main reason for doing so is to avoid the need to have a boiler-plate
> >> "silead,max-fingers=10" property in each silead touchscreen config.
> >> The second patch removes this boilerplate from all silead touchscreen
> >> configs in touchscreen_dmi.c .
> >>
> >> Dmitry, since touchscreen_dmi.c sees regular updates I believe it is
> >> best to merge the 2 patches separately. As long as I know that patch 1/2
> >> is queued for merging for say 6.11 then I can merge patch 2/2 independently
> >> for the same cycle.
> >
> > Why don't you merge both of them with my ack for the silead.c?
>
> That works for me too, thanks.
>
> One challenge here is that I typically send out new touchscreen_dmi
> entries as fixes. Are you ok with merging the silead change as a fix
> too ?
Sorry, I am not sure what you mean here. Do you mean you do not want to
wait for the next merge window and send it earlier? If so I'm fine with
it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH V1 1/5] dt-bindings: input: Add YAML to Awinic sar sensor.
From: Rob Herring @ 2024-05-31 1:36 UTC (permalink / raw)
To: wangshuaijie
Cc: dmitry.torokhov, krzk+dt, conor+dt, jeff, linux-input, devicetree,
linux-kernel, liweilei, kangjiajun
In-Reply-To: <20240529130608.783624-2-wangshuaijie@awinic.com>
On Wed, May 29, 2024 at 01:06:04PM +0000, wangshuaijie@awinic.com wrote:
> From: shuaijie wang <wangshuaijie@awinic.com>
>
> Add the awinic,aw_sar.yaml file to adapt to the awinic sar sensor driver.
>
> Signed-off-by: shuaijie wang <wangshuaijie@awinic.com>
> ---
> .../bindings/input/awinic,aw_sar.yaml | 110 ++++++++++++++++++
> 1 file changed, 110 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/awinic,aw_sar.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/awinic,aw_sar.yaml b/Documentation/devicetree/bindings/input/awinic,aw_sar.yaml
> new file mode 100644
> index 000000000000..ed4ec29c9b4d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/awinic,aw_sar.yaml
> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/awinic,aw_sar.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Awinic sar sensor driver family
> +
> +maintainers:
> + - Shuaijie Wang <wangshuaijie@awinic.com>
> +
> +properties:
> + compatible:
> + enum:
> + - awinic,aw_aw96103
> + - awinic,aw_aw96105
> + - awinic,aw_aw96303
> + - awinic,aw_aw96305
> + - awinic,aw_aw96308
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + sar-num:
Custom properties need vendor prefix.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + set the index of the sar sensor.
What is 'sar'? It's never defined.
How is the index determined? We generally don't do indexes in DT unless
there is some correlation to the h/w.
> +
> + vcc0-supply:
> + description:
> + Optional regulator for chip, 1.7V-3.6V.
> +
> + channel_use_flag:
vendor prefix needed plus use '-' rather than '_'. Here and elsewhere.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + The flag of channels used.
> + Configure according to the specific chip channel used.
> + Bit[31:0] Each bit represents a channel.
So a mask rather than a flag.
Up to 32 channels possible? If not, add constraints.
> + If the customer uses ch0 and ch2, then channel_use_flag=<0x05>
> +
> + aw_sar,update_fw:
> + type: boolean
> + description:
> + Choose if you want to update the firmware.
DT is mostly fixed. So someone would want to update the firmware every
time?
> +
> + aw_sar,monitor_esd:
> + type: boolean
> + description:
> + Choose if you want to monitor ESD.
> +
> + aw_sar,pin_set_inter_pull-up:
> + type: boolean
> + description:
> + Choose if you want to set the interrupt pin to internal pull-up.
> +
> + aw_sar,using_pm_ops:
> + type: boolean
> + description:
> + Choose if you want to use suspend and resume related function.
OS configuration. Doesn't belong in DT.
> +
> + aw_sar,use_plug_cail:
> + type: boolean
> + description:
> + Choose If you want to perform calibration when plugging and unplugging the charger.
> +
> + start-mode:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + When connecting to aw963xx, select the location where the firmware starts.
> + set 0 if start in rom.
> + set 1 if start in ram
Looks like constraints.
> +
> + irq-mux:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + set csx as irq pin. config this field when connect to aw96308/aw96305BFOR
Constraints? Can you imply this based on the compatible?
> +
> +required:
> + - compatible
> + - reg
> + - sar-num
> + - interrupts
> + - channel_use_flag
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + awinic_sar@12 {
> + compatible = "awinic,aw_sar";
> + reg = <0x12>;
> + sar-num = < 0 >;
> + interrupt-parent = < &tlmm >;
> + interrupts = <72 0>;
> + //vcc0-supply = <&pm660l_l4>;
Why commented?
> + channel_use_flag = <0xff>;
> + aw_sar,update_fw;
> + //aw_sar,monitor_esd;
> + start-mode = < 1 >;
> + irq-mux = < 2 >;
> + };
> + };
> --
> 2.45.1
>
^ permalink raw reply
* Re: [PATCH v12 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
From: kernel test robot @ 2024-05-31 2:14 UTC (permalink / raw)
To: Kamel Bouhara, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Henrik Rydberg, linux-input, linux-kernel,
devicetree, Marco Felsch, Jeff LaBundy
Cc: oe-kbuild-all, catalin.popescu, mark.satterthwaite,
Thomas Petazzoni, Gregory Clement, bsp-development.geo,
Kamel Bouhara
In-Reply-To: <20240529091004.107256-4-kamel.bouhara@bootlin.com>
Hi Kamel,
kernel test robot noticed the following build errors:
[auto build test ERROR on dtor-input/next]
[also build test ERROR on dtor-input/for-linus robh/for-next krzk-dt/for-next linus/master v6.10-rc1 next-20240529]
[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#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Kamel-Bouhara/dt-bindings-vendor-prefixes-Add-TouchNetix-AS/20240529-171328
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link: https://lore.kernel.org/r/20240529091004.107256-4-kamel.bouhara%40bootlin.com
patch subject: [PATCH v12 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
config: x86_64-randconfig-103-20240531 (https://download.01.org/0day-ci/archive/20240531/202405311035.5QZSREJv-lkp@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240531/202405311035.5QZSREJv-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405311035.5QZSREJv-lkp@intel.com/
All errors (new ones prefixed by >>):
ld: drivers/input/touchscreen/touchnetix_axiom.o: in function `axiom_handle_events':
>> drivers/input/touchscreen/touchnetix_axiom.c:473:(.text+0x245f): undefined reference to `crc16'
vim +473 drivers/input/touchscreen/touchnetix_axiom.c
442
443 /*
444 * Validates the crc and demultiplexes the axiom reports to the appropriate
445 * report handler
446 */
447 static int axiom_handle_events(struct axiom_data *ts)
448 {
449 struct input_dev *input_dev = ts->input_dev;
450 u8 *report_data = ts->rx_buf;
451 struct device *dev = ts->dev;
452 u16 crc_report;
453 u8 *crc_bytes;
454 u16 crc_calc;
455 int error;
456 u8 len;
457
458 error = axiom_read(ts, AXIOM_REPORT_USAGE_ID, 0, report_data, ts->max_report_len);
459 if (error)
460 return error;
461
462 len = (report_data[0] & AXIOM_COMMS_REPORT_LEN_MASK) << 1;
463 if (len <= 2) {
464 dev_err(dev, "Zero length report discarded.\n");
465 return -ENODATA;
466 }
467
468 /* Validate the report CRC */
469 crc_bytes = &report_data[len];
470
471 crc_report = get_unaligned_le16(crc_bytes - 2);
472 /* Length is in 16 bit words and remove the size of the CRC16 itself */
> 473 crc_calc = crc16(0, report_data, (len - 2));
474
475 if (crc_calc != crc_report) {
476 dev_err(dev,
477 "CRC mismatch! Expected: %#x, Calculated CRC: %#x.\n",
478 crc_report, crc_calc);
479 return -EINVAL;
480 }
481
482 switch (report_data[1]) {
483 case AXIOM_USAGE_2DCTS_REPORT_ID:
484 if (axiom_process_u41_report(ts, &report_data[1])) {
485 input_mt_sync_frame(input_dev);
486 input_sync(input_dev);
487 }
488 break;
489
490 case AXIOM_USAGE_2AUX_REPORT_ID:
491 /* This is an aux report (force) */
492 axiom_process_u46_report(ts, &report_data[1]);
493 input_mt_sync(input_dev);
494 input_sync(input_dev);
495 break;
496
497 case AXIOM_USAGE_2HB_REPORT_ID:
498 /* This is a heartbeat report */
499 break;
500 default:
501 return -EINVAL;
502 }
503
504 return 0;
505 }
506
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/2] HID: intel-ish-hid: fix endian-conversion
From: srinivas pandruvada @ 2024-05-31 3:49 UTC (permalink / raw)
To: Arnd Bergmann, Lixu Zhang, Arnd Bergmann, Jiri Kosina,
Benjamin Tissoires
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <508d40bb-f2df-469a-9f94-58b41a28f53a@app.fastmail.com>
On Wed, 2024-05-29 at 15:18 +0200, Arnd Bergmann wrote:
> On Wed, May 29, 2024, at 09:05, Zhang, Lixu wrote:
>
> > >
> > > for (i = 0; i < fragment->fragment_cnt && offset <
> > > ish_fw->size; i++) {
> > You added a parameter fragment_count, but you didn't use it. Did
> > you
> > intend to use it here?
> >
>
> My mistake, that was again broken in my incorrect
> rebase.
>
Do you have updated patch? Lixu can try and make sure that the
functionality is not broken by changes.
Thanks,
Srinivas
> Arnd
^ permalink raw reply
* Re: [PATCH 0/2] Input: silead - Always support 10 fingers
From: Hans de Goede @ 2024-05-31 6:25 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Ilpo Järvinen, Andy Shevchenko, linux-input,
platform-driver-x86
In-Reply-To: <ZlkRzbF_T8vgzxcr@google.com>
Hi,
On 5/31/24 1:54 AM, Dmitry Torokhov wrote:
> On Mon, May 27, 2024 at 09:46:54AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 5/26/24 6:19 AM, Dmitry Torokhov wrote:
>>> On Sat, May 25, 2024 at 09:38:52PM +0200, Hans de Goede wrote:
>>>> Hi all,
>>>>
>>>> The first patch in this series stops making the maximum number of supported
>>>> fingers in silead_ts configurable, replacing this with simply hardcoding it
>>>> to 10.
>>>>
>>>> The main reason for doing so is to avoid the need to have a boiler-plate
>>>> "silead,max-fingers=10" property in each silead touchscreen config.
>>>> The second patch removes this boilerplate from all silead touchscreen
>>>> configs in touchscreen_dmi.c .
>>>>
>>>> Dmitry, since touchscreen_dmi.c sees regular updates I believe it is
>>>> best to merge the 2 patches separately. As long as I know that patch 1/2
>>>> is queued for merging for say 6.11 then I can merge patch 2/2 independently
>>>> for the same cycle.
>>>
>>> Why don't you merge both of them with my ack for the silead.c?
>>
>> That works for me too, thanks.
>>
>> One challenge here is that I typically send out new touchscreen_dmi
>> entries as fixes. Are you ok with merging the silead change as a fix
>> too ?
>
> Sorry, I am not sure what you mean here. Do you mean you do not want to
> wait for the next merge window and send it earlier?
Yes that is what I meant, sorry for not being clear.
> If so I'm fine with it.
Thank you.
Regards,
Hans
^ permalink raw reply
* [syzbot] Monthly input report (May 2024)
From: syzbot @ 2024-05-31 6:48 UTC (permalink / raw)
To: linux-input, linux-kernel, syzkaller-bugs
Hello input maintainers/developers,
This is a 31-day syzbot report for the input subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/input
During the period, 4 new issues were detected and 0 were fixed.
In total, 24 issues are still open and 52 have been fixed so far.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 11549 Yes WARNING in input_mt_init_slots
https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5
<2> 958 Yes WARNING in implement
https://syzkaller.appspot.com/bug?extid=38e7237add3712479d65
<3> 646 No possible deadlock in evdev_pass_values (2)
https://syzkaller.appspot.com/bug?extid=13d3cb2a3dc61e6092f5
<4> 380 Yes INFO: task hung in uhid_char_release
https://syzkaller.appspot.com/bug?extid=8fe2d362af0e1cba8735
<5> 313 Yes WARNING in cm109_urb_irq_callback/usb_submit_urb
https://syzkaller.appspot.com/bug?extid=2d6d691af5ab4b7e66df
<6> 19 Yes possible deadlock in uinput_request_submit
https://syzkaller.appspot.com/bug?extid=159077b1355b8cd72757
<7> 13 Yes WARNING in cm109_input_open/usb_submit_urb (3)
https://syzkaller.appspot.com/bug?extid=ac0f9c4cc1e034160492
<8> 8 Yes INFO: task hung in __input_unregister_device (5)
https://syzkaller.appspot.com/bug?extid=78e2288f58b881ed3c45
<9> 4 Yes WARNING in __input_unregister_device
https://syzkaller.appspot.com/bug?extid=b03b0fc32e288051502d
<10> 4 Yes WARNING in input_unregister_device (2)
https://syzkaller.appspot.com/bug?extid=617f4ccb03b9869f6494
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH V1 5/5] Add support for Awinic sar sensor.
From: Dan Carpenter @ 2024-05-31 8:12 UTC (permalink / raw)
To: oe-kbuild, wangshuaijie, dmitry.torokhov, robh, krzk+dt, conor+dt,
jeff, linux-input, devicetree, linux-kernel
Cc: lkp, oe-kbuild-all, wangshuaijie, liweilei, kangjiajun
In-Reply-To: <20240529130608.783624-6-wangshuaijie@awinic.com>
Hi,
kernel test robot noticed the following build warnings:
url: https://github.com/intel-lab-lkp/linux/commits/wangshuaijie-awinic-com/dt-bindings-input-Add-YAML-to-Awinic-sar-sensor/20240529-211303
base: e0cce98fe279b64f4a7d81b7f5c3a23d80b92fbc
patch link: https://lore.kernel.org/r/20240529130608.783624-6-wangshuaijie%40awinic.com
patch subject: [PATCH V1 5/5] Add support for Awinic sar sensor.
config: riscv-randconfig-r071-20240530 (https://download.01.org/0day-ci/archive/20240531/202405310138.ry5jf9hL-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 13.2.0
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202405310138.ry5jf9hL-lkp@intel.com/
New smatch warnings:
drivers/input/misc/aw_sar/aw_sar.c:221 aw_sar_load_bin_comm() warn: 'fw' from request_firmware() not released on lines: 217.
drivers/input/misc/aw_sar/aw_sar.c:283 aw_sar_irq() error: uninitialized symbol 'irq_status'.
drivers/input/misc/aw_sar/./aw9610x/aw9610x.c:479 aw9610x_get_chip_version() error: __builtin_memcpy() 'aw9610x->chip_name[__builtin_choose_expr((4 == 1), __builtin_strlen(aw9610x->chip_name), __fortify_strlen(aw9610x->chip_name))]' too small (1 vs 2)
drivers/input/misc/aw_sar/./aw963xx/aw963xx.c:227 aw963xx_sram_data_write() error: uninitialized symbol 'ret'.
drivers/input/misc/aw_sar/./aw963xx/aw963xx.c:522 aw963xx_get_cap_offset() warn: inconsistent indenting
Old smatch warnings:
drivers/input/misc/aw_sar/./aw963xx/aw963xx.c:557 aw963xx_get_cap_offset() warn: inconsistent indenting
vim +/fw +221 drivers/input/misc/aw_sar/aw_sar.c
e5df082e247559 shuaijie wang 2024-05-29 203 static int32_t aw_sar_load_bin_comm(struct aw_sar *p_sar)
e5df082e247559 shuaijie wang 2024-05-29 204 {
e5df082e247559 shuaijie wang 2024-05-29 205 const struct firmware *fw;
e5df082e247559 shuaijie wang 2024-05-29 206 int32_t ret;
e5df082e247559 shuaijie wang 2024-05-29 207
e5df082e247559 shuaijie wang 2024-05-29 208 ret = request_firmware(&fw, p_sar->load_bin.bin_name, p_sar->dev);
e5df082e247559 shuaijie wang 2024-05-29 209 if (ret != 0) {
e5df082e247559 shuaijie wang 2024-05-29 210 dev_err(p_sar->dev, "parse %s error!", p_sar->load_bin.bin_name);
e5df082e247559 shuaijie wang 2024-05-29 211 return ret;
e5df082e247559 shuaijie wang 2024-05-29 212 }
e5df082e247559 shuaijie wang 2024-05-29 213
e5df082e247559 shuaijie wang 2024-05-29 214 ret = aw_sar_parse_bin(fw, p_sar);
e5df082e247559 shuaijie wang 2024-05-29 215 if (ret != 0) {
e5df082e247559 shuaijie wang 2024-05-29 216 dev_err(p_sar->dev, "reg_bin %s load error!", p_sar->load_bin.bin_name);
release_firmware(fw);
e5df082e247559 shuaijie wang 2024-05-29 217 return ret;
e5df082e247559 shuaijie wang 2024-05-29 218 }
e5df082e247559 shuaijie wang 2024-05-29 219 release_firmware(fw);
e5df082e247559 shuaijie wang 2024-05-29 220
e5df082e247559 shuaijie wang 2024-05-29 @221 return 0;
e5df082e247559 shuaijie wang 2024-05-29 222 }
e5df082e247559 shuaijie wang 2024-05-29 223
e5df082e247559 shuaijie wang 2024-05-29 224 static int32_t aw_sar_parse_dts_comm(struct device *dev, struct device_node *np,
e5df082e247559 shuaijie wang 2024-05-29 225 struct aw_sar_dts_info *p_dts_info)
e5df082e247559 shuaijie wang 2024-05-29 226 {
e5df082e247559 shuaijie wang 2024-05-29 227 int32_t val;
e5df082e247559 shuaijie wang 2024-05-29 228
e5df082e247559 shuaijie wang 2024-05-29 229 val = of_property_read_u32(np, "sar-num", &p_dts_info->sar_num);
e5df082e247559 shuaijie wang 2024-05-29 230 dev_info(dev, "sar num = %d", p_dts_info->sar_num);
e5df082e247559 shuaijie wang 2024-05-29 231 if (val != 0) {
e5df082e247559 shuaijie wang 2024-05-29 232 dev_err(dev, "multiple sar failed!");
e5df082e247559 shuaijie wang 2024-05-29 233 return -EINVAL;
e5df082e247559 shuaijie wang 2024-05-29 234 }
e5df082e247559 shuaijie wang 2024-05-29 235
e5df082e247559 shuaijie wang 2024-05-29 236 p_dts_info->irq_gpio = of_get_named_gpio(np, "irq-gpio", 0);
e5df082e247559 shuaijie wang 2024-05-29 237 if (p_dts_info->irq_gpio < 0) {
e5df082e247559 shuaijie wang 2024-05-29 238 p_dts_info->irq_gpio = -1;
e5df082e247559 shuaijie wang 2024-05-29 239 dev_err(dev, "no irq gpio provided.");
e5df082e247559 shuaijie wang 2024-05-29 240 return -EINVAL;
e5df082e247559 shuaijie wang 2024-05-29 241 }
e5df082e247559 shuaijie wang 2024-05-29 242
e5df082e247559 shuaijie wang 2024-05-29 243 val = of_property_read_u32(np, "channel_use_flag", &p_dts_info->channel_use_flag);
e5df082e247559 shuaijie wang 2024-05-29 244 if (val != 0) {
e5df082e247559 shuaijie wang 2024-05-29 245 dev_err(dev, "channel_use_flag failed!");
e5df082e247559 shuaijie wang 2024-05-29 246 return -EINVAL;
e5df082e247559 shuaijie wang 2024-05-29 247 }
e5df082e247559 shuaijie wang 2024-05-29 248
e5df082e247559 shuaijie wang 2024-05-29 249 //GPIO is set as internal pull-up input
e5df082e247559 shuaijie wang 2024-05-29 250 p_dts_info->use_inter_pull_up = of_property_read_bool(np, "aw_sar,pin_set_inter_pull-up");
e5df082e247559 shuaijie wang 2024-05-29 251 p_dts_info->use_pm = of_property_read_bool(np, "aw_sar,using_pm_ops");
e5df082e247559 shuaijie wang 2024-05-29 252 p_dts_info->update_fw_flag = of_property_read_bool(np, "aw_sar,update_fw");
e5df082e247559 shuaijie wang 2024-05-29 253 p_dts_info->use_plug_cail_flag = of_property_read_bool(np, "aw_sar,use_plug_cail");
e5df082e247559 shuaijie wang 2024-05-29 254 p_dts_info->monitor_esd_flag = of_property_read_bool(np, "aw_sar,monitor_esd");
e5df082e247559 shuaijie wang 2024-05-29 255
e5df082e247559 shuaijie wang 2024-05-29 256 return 0;
e5df082e247559 shuaijie wang 2024-05-29 257 }
e5df082e247559 shuaijie wang 2024-05-29 258
e5df082e247559 shuaijie wang 2024-05-29 259 static int32_t aw_sar_parse_dts(struct aw_sar *p_sar)
e5df082e247559 shuaijie wang 2024-05-29 260 {
e5df082e247559 shuaijie wang 2024-05-29 261 int32_t ret;
e5df082e247559 shuaijie wang 2024-05-29 262
e5df082e247559 shuaijie wang 2024-05-29 263 ret = aw_sar_parse_dts_comm(p_sar->dev, p_sar->i2c->dev.of_node, &p_sar->dts_info);
e5df082e247559 shuaijie wang 2024-05-29 264
e5df082e247559 shuaijie wang 2024-05-29 265 //Special requirements of SAR chip
e5df082e247559 shuaijie wang 2024-05-29 266 if (p_sar->p_sar_para->p_platform_config->p_add_parse_dts_fn != NULL)
e5df082e247559 shuaijie wang 2024-05-29 267 ret |= p_sar->p_sar_para->p_platform_config->p_add_parse_dts_fn(p_sar);
e5df082e247559 shuaijie wang 2024-05-29 268
e5df082e247559 shuaijie wang 2024-05-29 269 return ret;
e5df082e247559 shuaijie wang 2024-05-29 270 }
e5df082e247559 shuaijie wang 2024-05-29 271
e5df082e247559 shuaijie wang 2024-05-29 272 static irqreturn_t aw_sar_irq(int32_t irq, void *data)
e5df082e247559 shuaijie wang 2024-05-29 273 {
e5df082e247559 shuaijie wang 2024-05-29 274 struct aw_sar *p_sar = (struct aw_sar *)data;
e5df082e247559 shuaijie wang 2024-05-29 275 uint32_t irq_status;
e5df082e247559 shuaijie wang 2024-05-29 276
e5df082e247559 shuaijie wang 2024-05-29 277 //step1: read clear interrupt
e5df082e247559 shuaijie wang 2024-05-29 278 if (p_sar->p_sar_para->p_platform_config->p_irq_init->rc_irq_fn != NULL)
e5df082e247559 shuaijie wang 2024-05-29 279 irq_status = p_sar->p_sar_para->p_platform_config->p_irq_init->rc_irq_fn(p_sar->i2c);
e5df082e247559 shuaijie wang 2024-05-29 280
e5df082e247559 shuaijie wang 2024-05-29 281 //step2: Read the status register for status reporting
e5df082e247559 shuaijie wang 2024-05-29 282 if (p_sar->p_sar_para->p_platform_config->p_irq_init->irq_spec_handler_fn != NULL)
e5df082e247559 shuaijie wang 2024-05-29 @283 p_sar->p_sar_para->p_platform_config->p_irq_init->irq_spec_handler_fn(irq_status,
e5df082e247559 shuaijie wang 2024-05-29 284 p_sar);
Probably if ->irq_spec_handler_fn is non-NULL then ->rc_irq_fn is also
non-NULL, but the static checker doesn't know that so it warns about
uninitialized variables.
e5df082e247559 shuaijie wang 2024-05-29 285
e5df082e247559 shuaijie wang 2024-05-29 286 //step3: The chip
e5df082e247559 shuaijie wang 2024-05-29 287
e5df082e247559 shuaijie wang 2024-05-29 288 if ((!p_sar->dts_info.monitor_esd_flag) && (p_sar->fault_flag == AW_SAR_UNHEALTHY)) {
e5df082e247559 shuaijie wang 2024-05-29 289 p_sar->fault_flag = AW_SAR_HEALTHY;
e5df082e247559 shuaijie wang 2024-05-29 290 disable_irq_nosync(p_sar->irq_init.to_irq);
e5df082e247559 shuaijie wang 2024-05-29 291 p_sar->irq_init.host_irq_stat = IRQ_DISABLE;
e5df082e247559 shuaijie wang 2024-05-29 292 //aw_sar_soft_reset(p_sar);
e5df082e247559 shuaijie wang 2024-05-29 293 schedule_delayed_work(&p_sar->update_work, msecs_to_jiffies(500));
e5df082e247559 shuaijie wang 2024-05-29 294 }
e5df082e247559 shuaijie wang 2024-05-29 295
e5df082e247559 shuaijie wang 2024-05-29 296 return IRQ_HANDLED;
e5df082e247559 shuaijie wang 2024-05-29 297 }
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox