* Re: [PATCH] HID: Reorder fields in 'struct hid_input'
From: Jiri Kosina @ 2023-08-14 9:21 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Benjamin Tissoires, linux-kernel, kernel-janitors, linux-input
In-Reply-To: <9accb4ebd1247e2f2acc77dd053f67e60bf8d283.1687079502.git.christophe.jaillet@wanadoo.fr>
On Sun, 18 Jun 2023, Christophe JAILLET wrote:
> Group some variables based on their sizes to reduce hole and avoid padding.
> On x86_64, this shrinks the size of 'struct hid_input'
> from 72 to 64 bytes.
>
> It saves a few bytes of memory and is more cache-line friendly.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Rename HID++ "internal" error constant
From: Jiri Kosina @ 2023-08-14 9:22 UTC (permalink / raw)
To: Bastien Nocera
Cc: linux-input, linux-kernel, Benjamin Tissoires,
Peter F . Patel-Schneider, Filipe Laíns, Nestor Lopez Casado
In-Reply-To: <20230620085014.542370-1-hadess@hadess.net>
On Tue, 20 Jun 2023, Bastien Nocera wrote:
> As per the upstream "hidpp" helpers commit:
> "
> There has been some confusion about error value 5 but feature specs that
> refer to it generally use NOT_ALLOWED.
> "
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/2] HID: roccat: make all 'class' structures const
From: Jiri Kosina @ 2023-08-14 9:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-input, linux-kernel, Ivan Orlov, Stefan Achatz,
Benjamin Tissoires
In-Reply-To: <20230620183141.681353-3-gregkh@linuxfoundation.org>
On Tue, 20 Jun 2023, Greg Kroah-Hartman wrote:
> From: Ivan Orlov <ivan.orlov0322@gmail.com>
>
> Now that the driver core allows for struct class to be in read-only
> memory, making all 'class' structures to be declared at build time
> placing them into read-only memory, instead of having to be dynamically
> allocated at load time.
>
> Cc: Stefan Achatz <erazor_de@users.sourceforge.net>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: linux-input@vger.kernel.org
> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Both patches now applied, sorry for the delay.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v1] HID: i2c-hid: use print_hex_dump_debug to print report descriptor
From: Jiri Kosina @ 2023-08-14 9:26 UTC (permalink / raw)
To: Riwen Lu
Cc: benjamin.tissoires, dmitry.torokhov, linux, hdegoede, rrangel,
u.kleine-koenig, linux-input, linux-kernel, Riwen Lu
In-Reply-To: <TYCP286MB260706B19C5E30EE2774784EB129A@TYCP286MB2607.JPNP286.PROD.OUTLOOK.COM>
On Mon, 3 Jul 2023, Riwen Lu wrote:
> From: Riwen Lu <luriwen@kylinos.cn>
>
> The format '%*ph' print up to 64 bytes long as a hex string with ' '
> sepatator. Usually the size of report descriptor is larger than 64
> bytes, so consider using print_hex_dump_debug to print out all of it for
> better debugging.
>
> Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
> ---
> drivers/hid/i2c-hid/i2c-hid-core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> index efbba0465eef..8e97fc01c852 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -772,7 +772,9 @@ static int i2c_hid_parse(struct hid_device *hid)
> }
> }
>
> - i2c_hid_dbg(ihid, "Report Descriptor: %*ph\n", rsize, rdesc);
> + i2c_hid_dbg(ihid, "Report Descriptor\n");
> + print_hex_dump_debug(" ", DUMP_PREFIX_OFFSET, 16, 1,
> + rdesc, rsize, false);
But that would dump it unconditionally, while i2c_hid_dbg() is
conditional.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v6] HID: steelseries: Add support for Arctis 1 XBox
From: Jiri Kosina @ 2023-08-14 9:28 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <20230703181115.61975-1-hadess@hadess.net>
On Mon, 3 Jul 2023, Bastien Nocera wrote:
> Add support for the Steelseries Arctis 1 XBox headset. This driver
> will export the battery information from the headset, as well as the
> "wireless_status" property.
>
> Signed-off-by: Bastien Nocera <hadess@hadess.net>
This is now in hid.git#for-6.6/steelseries. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v1 00/12] HID: cp2112: Cleanups and refactorings
From: Jiri Kosina @ 2023-08-14 9:28 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <ZND/8wd67YbGs8d5@smile.fi.intel.com>
On Mon, 7 Aug 2023, Andy Shevchenko wrote:
> > > > > After I updated GPIO library for the case Benjamin has with CP2112,
> > > > > I have a brief look into the CP2112 driver itself.
> > > > >
> > > > > From GPIO perspective it has two main (maitenance) issues:
> > > > > - usage of ->to_irq() with IRQ chip present;
> > > > > - having IRQ chip not immutable.
> > > > >
> > > > > Besides that there are plenty small cleanups here and there.
> > > > > Hence this series.
> > > >
> > > > Any comments on this?
> > >
> > > Gentle ping^2 for this...
> > >
> > > Anything should I do to improve it or is it okay to go as is?
> >
> > I have been off pretty much the whole July. I am now back and slowly
> > making my way through everything that accumulated, I will eventually get
> > to this.
> >
> > Thanks for the patience,
>
> Ah, okay, no worries and take your time!
>
> I was thinking more on Benjamin's answer as last time he had a hw setup
> to test... Not sure what the status of that now and if he has a chance
> to test this or busy enough with something else.
Ah, that would be of course nice. Benjamin?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 1/2] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Jiri Kosina @ 2023-08-14 9:34 UTC (permalink / raw)
To: Mavroudis Chatzilazaridis; +Cc: linux-input, benjamin.tissoires, lains, hadess
In-Reply-To: <20230716182320.85483-1-mavchatz@protonmail.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4] HID: hid-google-stadiaff: add support for Stadia force feedback
From: Jiri Kosina @ 2023-08-14 9:35 UTC (permalink / raw)
To: Fabio Baltieri
Cc: Benjamin Tissoires, Rahul Rameshbabu, linux-input, linux-kernel
In-Reply-To: <20230716204834.2879106-1-fabiobaltieri@chromium.org>
On Sun, 16 Jul 2023, Fabio Baltieri wrote:
> Add a hid-google-stadiaff module to support rumble based force feedback
> on the Google Stadia controller. This works using the HID output
> endpoint exposed on both the USB and BLE interface.
>
> Signed-off-by: Fabio Baltieri <fabiobaltieri@chromium.org>
Now queued in hid.git#for-6.6/google.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/3] HID: nvidia-shield: Remove led_classdev_unregister in thunderstrike_create
From: Jiri Kosina @ 2023-08-14 9:41 UTC (permalink / raw)
To: Rahul Rameshbabu; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20230807163620.16855-1-rrameshbabu@nvidia.com>
I have now applied the series to hid.git.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH Wacom EKR Battery Fixes 0/3]
From: Jiri Kosina @ 2023-08-14 9:44 UTC (permalink / raw)
To: Aaron Armstrong Skomra
Cc: linux-input, linux-kernel, benjamin.tissoires, pinglinux, Joshua,
jason.gerecke, stable
In-Reply-To: <20230725221936.123775-1-skomra@gmail.com>
On Tue, 25 Jul 2023, Aaron Armstrong Skomra wrote:
> Currently the ExpressKey Remote battery will persist indefinitely in
> /sys/class/power_supply. Remove the battery when we stop getting
> reports from the device.
>
> Also remove some unneccessary code and make an EKR struct name more
> descriptive.
I have now applied the series. Please look into your mail setup -- the
patches in the series were not part of one thread, but separate.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Add support for Logitech MX Anywhere 3 mouse
From: Jiri Kosina @ 2023-08-14 9:47 UTC (permalink / raw)
To: Maxim Mikityanskiy
Cc: Filipe Laíns, Bastien Nocera, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <20230809113832.123667-1-maxtram95@gmail.com>
On Wed, 9 Aug 2023, Maxim Mikityanskiy wrote:
> Add Logitech MX Anywhere 3 connected over Bluetooth to the device table
> to get hidpi scroll supported. USB connection over the Unifying receiver
> is already supported by the wildcard entry LDJ_DEVICE(HID_ANY_ID).
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: update my email address
From: Jiri Kosina @ 2023-08-14 9:55 UTC (permalink / raw)
To: David Rheinsberg; +Cc: linux-input, Benjamin Tissoires
In-Reply-To: <20230803134001.754936-1-david@readahead.eu>
On Thu, 3 Aug 2023, David Rheinsberg wrote:
> Update my email-address in MAINTAINERS to <david@readahead.eu>. Also add
> .mailmap entries to map my old surname and email-addresses.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v4 2/3] dt-bindings: input: qcom,pm8xxx-vib: add new SPMI vibrator module
From: Krzysztof Kozlowski @ 2023-08-14 10:06 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, linux-kernel, krzysztof.kozlowski+dt,
robh+dt, agross, andersson, dmitry.baryshkov, Konrad Dybcio,
Dmitry Torokhov, linux-input, devicetree
Cc: quic_collinsd, quic_subbaram, quic_kamalw, jestar
In-Reply-To: <20230731053712.2220898-3-quic_fenglinw@quicinc.com>
On 31/07/2023 07:37, Fenglin Wu wrote:
> Add compatible string 'qcom,spmi-vib-gen2' to support vibrator module
> inside PMI632, PMI7250B, PM7325B, PM7550BA.
>
> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> ---
> .../bindings/input/qcom,pm8xxx-vib.yaml | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> index c8832cd0d7da..4a2319fc1e3f 100644
> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> @@ -11,10 +11,18 @@ maintainers:
>
> properties:
> compatible:
> - enum:
> - - qcom,pm8058-vib
> - - qcom,pm8916-vib
> - - qcom,pm8921-vib
> + oneOf:
> + - enum:
> + - qcom,pm8058-vib
> + - qcom,pm8916-vib
> + - qcom,pm8921-vib
> + - items:
> + - enum:
> + - qcom,pmi632-vib
> + - qcom,pm7250b-vib
> + - qcom,pm7325b-vib
> + - qcom,pm7550b-vib
> + - const: qcom,spmi-vib-gen2
This does not seem to implement my comment:
"Entirely remove qcom,spmi-vib-gen2 and
qcom,spmi-vib-gen1.
Use device specific compatibles names only. As fallback and as first
compatible."
It's nice to respond that you disagree with it. Therefore, I am not
going to Ack it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 3/3] input: pm8xxx-vibrator: add new SPMI vibrator support
From: Krzysztof Kozlowski @ 2023-08-14 10:07 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, linux-kernel, krzysztof.kozlowski+dt,
robh+dt, agross, andersson, dmitry.baryshkov, Konrad Dybcio,
Dmitry Torokhov, linux-input
Cc: quic_collinsd, quic_subbaram, quic_kamalw, jestar
In-Reply-To: <20230731053712.2220898-4-quic_fenglinw@quicinc.com>
On 31/07/2023 07:37, Fenglin Wu wrote:
...
>
> pm8xxx_vib_set(vib, vib->active);
> @@ -266,6 +310,7 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
> { .compatible = "qcom,pm8058-vib", .data = &ssbi_vib_data },
> { .compatible = "qcom,pm8921-vib", .data = &ssbi_vib_data },
> { .compatible = "qcom,pm8916-vib", .data = &spmi_vib_data },
> + { .compatible = "qcom,spmi-vib-gen2", .data = &spmi_vib_gen2_data },
No, don't introduce new style of compatibles. All of the other cases use
device-specific compatibles. Keep style consistent, especially that
device specific is preferred.
Best regards,
Krzysztof
^ permalink raw reply
* [hid:for-6.6/steelseries 1/1] drivers/hid/hid-steelseries.c:378:12: sparse: sparse: symbol 'arctis_1_battery_request' was not declared. Should it be static?
From: kernel test robot @ 2023-08-14 17:58 UTC (permalink / raw)
To: Bastien Nocera; +Cc: oe-kbuild-all, linux-input, Jiri Kosina
tree: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-6.6/steelseries
head: a0c76896c3fbdc2e7c70b980b3bb38a6ac445971
commit: a0c76896c3fbdc2e7c70b980b3bb38a6ac445971 [1/1] HID: steelseries: Add support for Arctis 1 XBox
config: i386-randconfig-i061-20230814 (https://download.01.org/0day-ci/archive/20230815/202308150123.SRaAiV75-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce: (https://download.01.org/0day-ci/archive/20230815/202308150123.SRaAiV75-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/202308150123.SRaAiV75-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/hid/hid-steelseries.c:378:12: sparse: sparse: symbol 'arctis_1_battery_request' was not declared. Should it be static?
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [hid:for-6.6/steelseries 1/1] drivers/hid/hid-steelseries.c:378:12: sparse: sparse: symbol 'arctis_1_battery_request' was not declared. Should it be static?
From: Jiri Kosina @ 2023-08-14 19:21 UTC (permalink / raw)
To: kernel test robot; +Cc: Bastien Nocera, oe-kbuild-all, linux-input
In-Reply-To: <202308150123.SRaAiV75-lkp@intel.com>
On Tue, 15 Aug 2023, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-6.6/steelseries
> head: a0c76896c3fbdc2e7c70b980b3bb38a6ac445971
> commit: a0c76896c3fbdc2e7c70b980b3bb38a6ac445971 [1/1] HID: steelseries: Add support for Arctis 1 XBox
> config: i386-randconfig-i061-20230814 (https://download.01.org/0day-ci/archive/20230815/202308150123.SRaAiV75-lkp@intel.com/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
> reproduce: (https://download.01.org/0day-ci/archive/20230815/202308150123.SRaAiV75-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/202308150123.SRaAiV75-lkp@intel.com/
>
> sparse warnings: (new ones prefixed by >>)
> >> drivers/hid/hid-steelseries.c:378:12: sparse: sparse: symbol 'arctis_1_battery_request' was not declared. Should it be static?
Just pushed the patch below to hid.git as a fixup.
Thanks.
From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] HID: steelseries: arctis_1_battery_request[] should be static
arctis_1_battery_request[] is not used outside of this module, and as such
should be static.
Fixes: a0c76896c3fbdc2 ("HID: steelseries: Add support for Arctis 1 XBox")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-steelseries.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-steelseries.c b/drivers/hid/hid-steelseries.c
index 495377686123..43d2cf7153d7 100644
--- a/drivers/hid/hid-steelseries.c
+++ b/drivers/hid/hid-steelseries.c
@@ -375,7 +375,7 @@ static void steelseries_srws1_remove(struct hid_device *hdev)
#define STEELSERIES_HEADSET_BATTERY_TIMEOUT_MS 3000
#define ARCTIS_1_BATTERY_RESPONSE_LEN 8
-const char arctis_1_battery_request[] = { 0x06, 0x12 };
+static const char arctis_1_battery_request[] = { 0x06, 0x12 };
static int steelseries_headset_arctis_1_fetch_battery(struct hid_device *hdev)
{
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: [PATCH] Input: xpad - fix GPF in xpad_probe
From: Claudia De-Massari @ 2023-08-14 21:12 UTC (permalink / raw)
To: dzm91
Cc: chaorace, dmitry.torokhov, hust-os-kernel-patches, linux-input,
linux-kernel, matthias.benkmann, mkorpershoek, nate, pgriffais,
radon86dev, rojtberg, s.demassari, syzbot+a3f758b8d8cb7e49afec,
vi
Hello
I am the mother of Santosh De Massari .
santoshde-massari@mail .com
I have to tell you that he is diet last year.
Greetings
Claudia De-Massari
^ permalink raw reply
* Re: [PATCH 2/2] Input: cs40l50 - Initial support for Cirrus Logic CS40L50
From: James Ogletree @ 2023-08-14 21:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Dmitry Torokhov, Fred Treven, Ben Bright, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Peng Fan,
Jean Delvare, Jeff LaBundy, Randy Dunlap, Arnd Bergmann,
Eddie James, Jacky Bai, Markus Schneider-Pargmann, ChiYuan Huang,
Jerome Neanne, patches@cirrus.com, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <3f406442-d46e-7f9e-426d-22a96f893103@linaro.org>
> On Aug 10, 2023, at 1:12 AM, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>
> On 09/08/2023 20:02, James Ogletree wrote:
>>>> + if (cs40l50->vibe_workqueue) {
>>>> + flush_workqueue(cs40l50->vibe_workqueue);
>>>> + destroy_workqueue(cs40l50->vibe_workqueue);
>>>> + }
>>>> +
>>>> + gpiod_set_value_cansleep(cs40l50->reset_gpio, 1);
>>>> + regulator_bulk_disable(ARRAY_SIZE(cs40l50_supplies), cs40l50_supplies);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(cs40l50_remove);
>>>> +
>>>> +MODULE_DESCRIPTION("CS40L50 Advanced Haptic Driver");
>>>> +MODULE_AUTHOR("James Ogletree, Cirrus Logic Inc. <james.ogletree@cirrus.com>");
>>>> +MODULE_LICENSE("GPL");
>>>
>>> I don't think this is a module.
>>
>> It can be compiled as a module with CONFIG_INPUT_CS40L50=m. However, there is a
>> typo in the Kconfig entry description: the module will be called “cs40l50” not “cs40l50-core”.
>> That will be fixed.
>
> Really, *this* unit file can be compiled as module? Where is the
> module_xxx_driver() then?
>
As I understand it, the “module_XXX_driver()” has nothing to do with whether or not the file is built as a module, rather it just provides code to attach the driver to a bus. But this is a bus-agnostic, separate module (not a driver in itself) that provides implementation to cs40l26-i2c or cs40l26-spi drivers, which do contain that macro as they should. This doesn’t appear to be an uncommon pattern.
Regards,
James
^ permalink raw reply
* Re: [PATCH v4 2/3] dt-bindings: input: qcom,pm8xxx-vib: add new SPMI vibrator module
From: Fenglin Wu @ 2023-08-15 2:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, linux-arm-msm, linux-kernel,
krzysztof.kozlowski+dt, robh+dt, agross, andersson,
dmitry.baryshkov, Konrad Dybcio, Dmitry Torokhov, linux-input,
devicetree
Cc: quic_collinsd, quic_subbaram, quic_kamalw, jestar
In-Reply-To: <a1b1cead-17e4-2016-91a1-9ad9949ff9e3@linaro.org>
On 8/14/2023 6:06 PM, Krzysztof Kozlowski wrote:
> On 31/07/2023 07:37, Fenglin Wu wrote:
>> Add compatible string 'qcom,spmi-vib-gen2' to support vibrator module
>> inside PMI632, PMI7250B, PM7325B, PM7550BA.
>>
>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>> ---
>> .../bindings/input/qcom,pm8xxx-vib.yaml | 16 ++++++++++++----
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> index c8832cd0d7da..4a2319fc1e3f 100644
>> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> @@ -11,10 +11,18 @@ maintainers:
>>
>> properties:
>> compatible:
>> - enum:
>> - - qcom,pm8058-vib
>> - - qcom,pm8916-vib
>> - - qcom,pm8921-vib
>> + oneOf:
>> + - enum:
>> + - qcom,pm8058-vib
>> + - qcom,pm8916-vib
>> + - qcom,pm8921-vib
>> + - items:
>> + - enum:
>> + - qcom,pmi632-vib
>> + - qcom,pm7250b-vib
>> + - qcom,pm7325b-vib
>> + - qcom,pm7550b-vib
>> + - const: qcom,spmi-vib-gen2
>
> This does not seem to implement my comment:
>
> "Entirely remove qcom,spmi-vib-gen2 and
> qcom,spmi-vib-gen1.
>
> Use device specific compatibles names only. As fallback and as first
> compatible."
>
> It's nice to respond that you disagree with it. Therefore, I am not
> going to Ack it.
I saw your comments and I replied your later comments in v2:
https://lore.kernel.org/linux-arm-msm/b5e58172-beb5-0be3-834f-3f1db3e8b3b3@quicinc.com/.
It might not be a good place to follow the discussion though, I am
pasting my last reply below:
'Sorry, I forgot to mention, in v3, I added the 'reg' value to the
register offset and no longer hard code the 16-bit register address,
that makes the vibrators inside PMI632/PM7250B/PM7325B/PM7550BA all
compatible, and that was another motivation of adding a generic
compatible string and make the others as the fallback.
This will be still the case in v4, I might keep it similar in v3 but
just drop "qcom,spmi-vib-gen1" '
Anyway, if this is still not a good reason to add a generic compatible
string, I can revert it back to use device specific compatible string
only in next patch.
Thanks
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 2/2] Input: cs40l50 - Initial support for Cirrus Logic CS40L50
From: Krzysztof Kozlowski @ 2023-08-15 5:08 UTC (permalink / raw)
To: James Ogletree
Cc: Dmitry Torokhov, Fred Treven, Ben Bright, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Peng Fan,
Jean Delvare, Jeff LaBundy, Randy Dunlap, Arnd Bergmann,
Eddie James, Jacky Bai, Markus Schneider-Pargmann, ChiYuan Huang,
Jerome Neanne, patches@cirrus.com, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <E3A9D2CF-333D-4238-8013-346135AC001B@cirrus.com>
On 14/08/2023 23:44, James Ogletree wrote:
>>>> I don't think this is a module.
>>>
>>> It can be compiled as a module with CONFIG_INPUT_CS40L50=m. However, there is a
>>> typo in the Kconfig entry description: the module will be called “cs40l50” not “cs40l50-core”.
>>> That will be fixed.
>>
>> Really, *this* unit file can be compiled as module? Where is the
>> module_xxx_driver() then?
>>
>
> As I understand it, the “module_XXX_driver()” has nothing to do with whether or not the file is built as a module, rather it just provides code to attach the driver to a bus. But this is a bus-agnostic, separate module (not a driver in itself) that provides implementation to cs40l26-i2c or cs40l26-spi drivers, which do contain that macro as they should. This doesn’t appear to be an uncommon pattern.
I see now in the Makefile that it can be indeed built as module and
compiled on its own. It's fine then.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/3] dt-bindings: input: qcom,pm8xxx-vib: add new SPMI vibrator module
From: Krzysztof Kozlowski @ 2023-08-15 5:10 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, linux-kernel, krzysztof.kozlowski+dt,
robh+dt, agross, andersson, dmitry.baryshkov, Konrad Dybcio,
Dmitry Torokhov, linux-input, devicetree
Cc: quic_collinsd, quic_subbaram, quic_kamalw, jestar
In-Reply-To: <19e45248-5fff-d806-81f2-feea56d7778d@quicinc.com>
On 15/08/2023 04:20, Fenglin Wu wrote:
>
>
> On 8/14/2023 6:06 PM, Krzysztof Kozlowski wrote:
>> On 31/07/2023 07:37, Fenglin Wu wrote:
>>> Add compatible string 'qcom,spmi-vib-gen2' to support vibrator module
>>> inside PMI632, PMI7250B, PM7325B, PM7550BA.
>>>
>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>> ---
>>> .../bindings/input/qcom,pm8xxx-vib.yaml | 16 ++++++++++++----
>>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> index c8832cd0d7da..4a2319fc1e3f 100644
>>> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> @@ -11,10 +11,18 @@ maintainers:
>>>
>>> properties:
>>> compatible:
>>> - enum:
>>> - - qcom,pm8058-vib
>>> - - qcom,pm8916-vib
>>> - - qcom,pm8921-vib
>>> + oneOf:
>>> + - enum:
>>> + - qcom,pm8058-vib
>>> + - qcom,pm8916-vib
>>> + - qcom,pm8921-vib
>>> + - items:
>>> + - enum:
>>> + - qcom,pmi632-vib
>>> + - qcom,pm7250b-vib
>>> + - qcom,pm7325b-vib
>>> + - qcom,pm7550b-vib
>>> + - const: qcom,spmi-vib-gen2
>>
>> This does not seem to implement my comment:
>>
>> "Entirely remove qcom,spmi-vib-gen2 and
>> qcom,spmi-vib-gen1.
>>
>> Use device specific compatibles names only. As fallback and as first
>> compatible."
>>
>> It's nice to respond that you disagree with it. Therefore, I am not
>> going to Ack it.
>
> I saw your comments and I replied your later comments in v2:
> https://lore.kernel.org/linux-arm-msm/b5e58172-beb5-0be3-834f-3f1db3e8b3b3@quicinc.com/.
> It might not be a good place to follow the discussion though, I am
> pasting my last reply below:
>
> 'Sorry, I forgot to mention, in v3, I added the 'reg' value to the
> register offset and no longer hard code the 16-bit register address,
> that makes the vibrators inside PMI632/PM7250B/PM7325B/PM7550BA all
> compatible, and that was another motivation of adding a generic
> compatible string and make the others as the fallback.
>
> This will be still the case in v4, I might keep it similar in v3 but
> just drop "qcom,spmi-vib-gen1" '
>
> Anyway, if this is still not a good reason to add a generic compatible
> string, I can revert it back to use device specific compatible string
> only in next patch.
I just don't see how this argument is anyhow related to what I said. I
did not comment on removing the fallback. I said use specific compatible
as fallback.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v5 3/3] input: pm8xxx-vibrator: add new SPMI vibrator support
From: Fenglin Wu @ 2023-08-15 6:03 UTC (permalink / raw)
To: linux-arm-msm, linux-kernel, krzysztof.kozlowski+dt, robh+dt,
agross, andersson, dmitry.baryshkov, Konrad Dybcio,
Dmitry Torokhov, linux-input
Cc: quic_collinsd, quic_subbaram, quic_fenglinw, quic_kamalw, jestar,
Luca Weiss
In-Reply-To: <20230815060314.352103-1-quic_fenglinw@quicinc.com>
Add new SPMI vibrator module which is very similar to the SPMI vibrator
module inside PM8916 but just has a finer drive voltage step (1mV vs
100mV) hence its drive level control is expanded to across 2 registers.
The vibrator module can be found in Qualcomm PMIC PMI632, then following
PM7250B, PM7325B, PM7550BA PMICs.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # sdm632-fairphone-fp3 (pmi632)
---
drivers/input/misc/pm8xxx-vibrator.c | 55 +++++++++++++++++++++++++---
1 file changed, 50 insertions(+), 5 deletions(-)
diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
index d6b468324c77..990e8a9ac018 100644
--- a/drivers/input/misc/pm8xxx-vibrator.c
+++ b/drivers/input/misc/pm8xxx-vibrator.c
@@ -21,6 +21,13 @@
#define SPMI_VIB_DRV_LEVEL_MASK GENMASK(4, 0)
#define SPMI_VIB_DRV_SHIFT 0
+#define SPMI_VIB_GEN2_DRV_REG 0x40
+#define SPMI_VIB_GEN2_DRV_MASK GENMASK(7, 0)
+#define SPMI_VIB_GEN2_DRV_SHIFT 0
+#define SPMI_VIB_GEN2_DRV2_REG 0x41
+#define SPMI_VIB_GEN2_DRV2_MASK GENMASK(3, 0)
+#define SPMI_VIB_GEN2_DRV2_SHIFT 8
+
#define SPMI_VIB_EN_REG 0x46
#define SPMI_VIB_EN_BIT BIT(7)
@@ -33,12 +40,14 @@
enum vib_hw_type {
SSBI_VIB,
SPMI_VIB,
+ SPMI_VIB_GEN2
};
struct pm8xxx_vib_data {
enum vib_hw_type hw_type;
unsigned int enable_addr;
unsigned int drv_addr;
+ unsigned int drv2_addr;
};
static const struct pm8xxx_vib_data ssbi_vib_data = {
@@ -52,6 +61,13 @@ static const struct pm8xxx_vib_data spmi_vib_data = {
.drv_addr = SPMI_VIB_DRV_REG,
};
+static const struct pm8xxx_vib_data spmi_vib_gen2_data = {
+ .hw_type = SPMI_VIB_GEN2,
+ .enable_addr = SPMI_VIB_EN_REG,
+ .drv_addr = SPMI_VIB_GEN2_DRV_REG,
+ .drv2_addr = SPMI_VIB_GEN2_DRV2_REG,
+};
+
/**
* struct pm8xxx_vib - structure to hold vibrator data
* @vib_input_dev: input device supporting force feedback
@@ -85,12 +101,24 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
{
int rc;
unsigned int val = vib->reg_vib_drv;
- u32 mask = SPMI_VIB_DRV_LEVEL_MASK;
- u32 shift = SPMI_VIB_DRV_SHIFT;
+ u32 mask, shift;
- if (vib->data->hw_type == SSBI_VIB) {
+
+ switch (vib->data->hw_type) {
+ case SSBI_VIB:
mask = SSBI_VIB_DRV_LEVEL_MASK;
shift = SSBI_VIB_DRV_SHIFT;
+ break;
+ case SPMI_VIB:
+ mask = SPMI_VIB_DRV_LEVEL_MASK;
+ shift = SPMI_VIB_DRV_SHIFT;
+ break;
+ case SPMI_VIB_GEN2:
+ mask = SPMI_VIB_GEN2_DRV_MASK;
+ shift = SPMI_VIB_GEN2_DRV_SHIFT;
+ break;
+ default:
+ return -EINVAL;
}
if (on)
@@ -104,6 +132,19 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
vib->reg_vib_drv = val;
+ if (vib->data->hw_type == SPMI_VIB_GEN2) {
+ mask = SPMI_VIB_GEN2_DRV2_MASK;
+ shift = SPMI_VIB_GEN2_DRV2_SHIFT;
+ if (on)
+ val = (vib->level >> shift) & mask;
+ else
+ val = 0;
+ rc = regmap_update_bits(vib->regmap,
+ vib->reg_base + vib->data->drv2_addr, mask, val);
+ if (rc < 0)
+ return rc;
+ }
+
if (vib->data->hw_type == SSBI_VIB)
return 0;
@@ -128,10 +169,13 @@ static void pm8xxx_work_handler(struct work_struct *work)
vib->active = true;
vib->level = ((VIB_MAX_LEVELS * vib->speed) / MAX_FF_SPEED) +
VIB_MIN_LEVEL_mV;
- vib->level /= 100;
+ if (vib->data->hw_type != SPMI_VIB_GEN2)
+ vib->level /= 100;
} else {
vib->active = false;
- vib->level = VIB_MIN_LEVEL_mV / 100;
+ vib->level = VIB_MIN_LEVEL_mV;
+ if (vib->data->hw_type != SPMI_VIB_GEN2)
+ vib->level /= 100;
}
pm8xxx_vib_set(vib, vib->active);
@@ -266,6 +310,7 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
{ .compatible = "qcom,pm8058-vib", .data = &ssbi_vib_data },
{ .compatible = "qcom,pm8921-vib", .data = &ssbi_vib_data },
{ .compatible = "qcom,pm8916-vib", .data = &spmi_vib_data },
+ { .compatible = "qcom,pmi632-vib", .data = &spmi_vib_gen2_data },
{ }
};
MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v1] HID: i2c-hid: use print_hex_dump_debug to print report descriptor
From: Riwen Lu @ 2023-08-15 6:02 UTC (permalink / raw)
To: Jiri Kosina
Cc: benjamin.tissoires, dmitry.torokhov, linux, hdegoede, rrangel,
u.kleine-koenig, linux-input, linux-kernel, Riwen Lu
In-Reply-To: <nycvar.YFH.7.76.2308141126330.14207@cbobk.fhfr.pm>
在 2023/8/14 17:26, Jiri Kosina 写道:
> On Mon, 3 Jul 2023, Riwen Lu wrote:
>
>> From: Riwen Lu <luriwen@kylinos.cn>
>>
>> The format '%*ph' print up to 64 bytes long as a hex string with ' '
>> sepatator. Usually the size of report descriptor is larger than 64
>> bytes, so consider using print_hex_dump_debug to print out all of it for
>> better debugging.
>>
>> Signed-off-by: Riwen Lu <luriwen@kylinos.cn>
>> ---
>> drivers/hid/i2c-hid/i2c-hid-core.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
>> index efbba0465eef..8e97fc01c852 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
>> @@ -772,7 +772,9 @@ static int i2c_hid_parse(struct hid_device *hid)
>> }
>> }
>>
>> - i2c_hid_dbg(ihid, "Report Descriptor: %*ph\n", rsize, rdesc);
>> + i2c_hid_dbg(ihid, "Report Descriptor\n");
>> + print_hex_dump_debug(" ", DUMP_PREFIX_OFFSET, 16, 1,
>> + rdesc, rsize, false);
>
> But that would dump it unconditionally, while i2c_hid_dbg() is
> conditional.
>
Function print_hex_dump_debug() dump messages is as conditional as
i2c_hid_dbg().
The function i2c_hid_dbg() defines as follows:
#define i2c_hid_dbg(ihid, ...) dev_dbg(&(ihid)->client->dev, __VA_ARGS__)
dev_dbg() depends on the same macro as print_hex_dump_debug().
^ permalink raw reply
* [PATCH v5 2/3] dt-bindings: input: qcom,pm8xxx-vib: add new SPMI vibrator module
From: Fenglin Wu @ 2023-08-15 6:03 UTC (permalink / raw)
To: linux-arm-msm, linux-kernel, krzysztof.kozlowski+dt, robh+dt,
agross, andersson, dmitry.baryshkov, Konrad Dybcio,
Dmitry Torokhov, linux-input, devicetree
Cc: quic_collinsd, quic_subbaram, quic_fenglinw, quic_kamalw, jestar
In-Reply-To: <20230815060314.352103-1-quic_fenglinw@quicinc.com>
Add compatible strings to support vibrator module inside PMI632,
PMI7250B, PM7325B, PM7550BA.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
.../bindings/input/qcom,pm8xxx-vib.yaml | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
index c8832cd0d7da..72b72c67a9b6 100644
--- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
@@ -11,10 +11,17 @@ maintainers:
properties:
compatible:
- enum:
- - qcom,pm8058-vib
- - qcom,pm8916-vib
- - qcom,pm8921-vib
+ oneOf:
+ - enum:
+ - qcom,pm8058-vib
+ - qcom,pm8916-vib
+ - qcom,pm8921-vib
+ - items:
+ - enum:
+ - qcom,pm7250b-vib
+ - qcom,pm7325b-vib
+ - qcom,pm7550ba-vib
+ - const: qcom,pmi632-vib
reg:
maxItems: 1
--
2.25.1
^ permalink raw reply related
* [PATCH v5 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator
From: Fenglin Wu @ 2023-08-15 6:03 UTC (permalink / raw)
To: linux-arm-msm, linux-kernel, krzysztof.kozlowski+dt, robh+dt,
agross, andersson, dmitry.baryshkov, Konrad Dybcio,
Dmitry Torokhov, linux-input
Cc: quic_collinsd, quic_subbaram, quic_fenglinw, quic_kamalw, jestar
In-Reply-To: <20230815060314.352103-1-quic_fenglinw@quicinc.com>
Currently, all vibrator control register addresses are hard coded,
including the base address and the offset, it's not flexible to support
new SPMI vibrator module which is usually included in different PMICs
with different base address. Refactor this by defining register offset
with HW type combination, and register base address which is defined
in 'reg' property is added for SPMI vibrators.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
drivers/input/misc/pm8xxx-vibrator.c | 122 ++++++++++++++++-----------
1 file changed, 73 insertions(+), 49 deletions(-)
diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
index 04cb87efd799..d6b468324c77 100644
--- a/drivers/input/misc/pm8xxx-vibrator.c
+++ b/drivers/input/misc/pm8xxx-vibrator.c
@@ -12,36 +12,44 @@
#include <linux/regmap.h>
#include <linux/slab.h>
+#define SSBL_VIB_DRV_REG 0x4A
+#define SSBI_VIB_DRV_EN_MANUAL_MASK GENMASK(7, 2)
+#define SSBI_VIB_DRV_LEVEL_MASK GENMASK(7, 3)
+#define SSBI_VIB_DRV_SHIFT 3
+
+#define SPMI_VIB_DRV_REG 0x41
+#define SPMI_VIB_DRV_LEVEL_MASK GENMASK(4, 0)
+#define SPMI_VIB_DRV_SHIFT 0
+
+#define SPMI_VIB_EN_REG 0x46
+#define SPMI_VIB_EN_BIT BIT(7)
+
#define VIB_MAX_LEVEL_mV (3100)
#define VIB_MIN_LEVEL_mV (1200)
#define VIB_MAX_LEVELS (VIB_MAX_LEVEL_mV - VIB_MIN_LEVEL_mV)
#define MAX_FF_SPEED 0xff
-struct pm8xxx_regs {
- unsigned int enable_addr;
- unsigned int enable_mask;
+enum vib_hw_type {
+ SSBI_VIB,
+ SPMI_VIB,
+};
- unsigned int drv_addr;
- unsigned int drv_mask;
- unsigned int drv_shift;
- unsigned int drv_en_manual_mask;
+struct pm8xxx_vib_data {
+ enum vib_hw_type hw_type;
+ unsigned int enable_addr;
+ unsigned int drv_addr;
};
-static const struct pm8xxx_regs pm8058_regs = {
- .drv_addr = 0x4A,
- .drv_mask = 0xf8,
- .drv_shift = 3,
- .drv_en_manual_mask = 0xfc,
+static const struct pm8xxx_vib_data ssbi_vib_data = {
+ .hw_type = SSBI_VIB,
+ .drv_addr = SSBL_VIB_DRV_REG,
};
-static struct pm8xxx_regs pm8916_regs = {
- .enable_addr = 0xc046,
- .enable_mask = BIT(7),
- .drv_addr = 0xc041,
- .drv_mask = 0x1F,
- .drv_shift = 0,
- .drv_en_manual_mask = 0,
+static const struct pm8xxx_vib_data spmi_vib_data = {
+ .hw_type = SPMI_VIB,
+ .enable_addr = SPMI_VIB_EN_REG,
+ .drv_addr = SPMI_VIB_DRV_REG,
};
/**
@@ -49,7 +57,8 @@ static struct pm8xxx_regs pm8916_regs = {
* @vib_input_dev: input device supporting force feedback
* @work: work structure to set the vibration parameters
* @regmap: regmap for register read/write
- * @regs: registers' info
+ * @data: vibrator HW info
+ * @reg_base: the register base of the module
* @speed: speed of vibration set from userland
* @active: state of vibrator
* @level: level of vibration to set in the chip
@@ -59,7 +68,8 @@ struct pm8xxx_vib {
struct input_dev *vib_input_dev;
struct work_struct work;
struct regmap *regmap;
- const struct pm8xxx_regs *regs;
+ const struct pm8xxx_vib_data *data;
+ unsigned int reg_base;
int speed;
int level;
bool active;
@@ -75,24 +85,31 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
{
int rc;
unsigned int val = vib->reg_vib_drv;
- const struct pm8xxx_regs *regs = vib->regs;
+ u32 mask = SPMI_VIB_DRV_LEVEL_MASK;
+ u32 shift = SPMI_VIB_DRV_SHIFT;
+
+ if (vib->data->hw_type == SSBI_VIB) {
+ mask = SSBI_VIB_DRV_LEVEL_MASK;
+ shift = SSBI_VIB_DRV_SHIFT;
+ }
if (on)
- val |= (vib->level << regs->drv_shift) & regs->drv_mask;
+ val |= (vib->level << shift) & mask;
else
- val &= ~regs->drv_mask;
+ val &= ~mask;
- rc = regmap_write(vib->regmap, regs->drv_addr, val);
+ rc = regmap_update_bits(vib->regmap, vib->reg_base + vib->data->drv_addr, mask, val);
if (rc < 0)
return rc;
vib->reg_vib_drv = val;
- if (regs->enable_mask)
- rc = regmap_update_bits(vib->regmap, regs->enable_addr,
- regs->enable_mask, on ? ~0 : 0);
+ if (vib->data->hw_type == SSBI_VIB)
+ return 0;
- return rc;
+ mask = SPMI_VIB_EN_BIT;
+ val = on ? SPMI_VIB_EN_BIT : 0;
+ return regmap_update_bits(vib->regmap, vib->reg_base + vib->data->enable_addr, mask, val);
}
/**
@@ -102,13 +119,6 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
static void pm8xxx_work_handler(struct work_struct *work)
{
struct pm8xxx_vib *vib = container_of(work, struct pm8xxx_vib, work);
- const struct pm8xxx_regs *regs = vib->regs;
- int rc;
- unsigned int val;
-
- rc = regmap_read(vib->regmap, regs->drv_addr, &val);
- if (rc < 0)
- return;
/*
* pmic vibrator supports voltage ranges from 1.2 to 3.1V, so
@@ -168,9 +178,9 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
{
struct pm8xxx_vib *vib;
struct input_dev *input_dev;
+ const struct pm8xxx_vib_data *data;
int error;
- unsigned int val;
- const struct pm8xxx_regs *regs;
+ unsigned int val, reg_base;
vib = devm_kzalloc(&pdev->dev, sizeof(*vib), GFP_KERNEL);
if (!vib)
@@ -187,19 +197,33 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
INIT_WORK(&vib->work, pm8xxx_work_handler);
vib->vib_input_dev = input_dev;
- regs = of_device_get_match_data(&pdev->dev);
+ data = of_device_get_match_data(&pdev->dev);
+ if (!data)
+ return -EINVAL;
- /* operate in manual mode */
- error = regmap_read(vib->regmap, regs->drv_addr, &val);
- if (error < 0)
- return error;
+ if (data->hw_type != SSBI_VIB) {
+ error = fwnode_property_read_u32(pdev->dev.fwnode, "reg", ®_base);
+ if (error < 0) {
+ dev_err(&pdev->dev, "Failed to read reg address, rc=%d\n", error);
+ return error;
+ }
+
+ vib->reg_base += reg_base;
+ }
- val &= regs->drv_en_manual_mask;
- error = regmap_write(vib->regmap, regs->drv_addr, val);
+ error = regmap_read(vib->regmap, vib->reg_base + data->drv_addr, &val);
if (error < 0)
return error;
- vib->regs = regs;
+ /* operate in manual mode */
+ if (data->hw_type == SSBI_VIB) {
+ val &= SSBI_VIB_DRV_EN_MANUAL_MASK;
+ error = regmap_write(vib->regmap, vib->reg_base + data->drv_addr, val);
+ if (error < 0)
+ return error;
+ }
+
+ vib->data = data;
vib->reg_vib_drv = val;
input_dev->name = "pm8xxx_vib_ffmemless";
@@ -239,9 +263,9 @@ static int pm8xxx_vib_suspend(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(pm8xxx_vib_pm_ops, pm8xxx_vib_suspend, NULL);
static const struct of_device_id pm8xxx_vib_id_table[] = {
- { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
- { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
- { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
+ { .compatible = "qcom,pm8058-vib", .data = &ssbi_vib_data },
+ { .compatible = "qcom,pm8921-vib", .data = &ssbi_vib_data },
+ { .compatible = "qcom,pm8916-vib", .data = &spmi_vib_data },
{ }
};
MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
--
2.25.1
^ permalink raw reply related
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