| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <c64f79c8-7928-3243-265f-8536ed2aaf10@lucaceresoli.net>
Date: Fri, 15 Oct 2021 18:46:05 +0200
From: Luca Ceresoli <luca@...aceresoli.net>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
linux-kernel@...r.kernel.org
Cc: Lee Jones <lee.jones@...aro.org>, Rob Herring <robh+dt@...nel.org>,
Alessandro Zummo <a.zummo@...ertech.it>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Wim Van Sebroeck <wim@...ux-watchdog.org>,
Guenter Roeck <linux@...ck-us.net>, devicetree@...r.kernel.org,
linux-rtc@...r.kernel.org, linux-watchdog@...r.kernel.org,
Chiwoong Byun <woong.byun@...sung.com>,
Laxman Dewangan <ldewangan@...dia.com>
Subject: Re: [PATCH 8/8] rtc: max77686: add MAX77714 support
Hi,
On 12/10/21 10:20, Krzysztof Kozlowski wrote:
> On 11/10/2021 18:12, Luca Ceresoli wrote:
>> Hi,
>>
>> see below for the issues with interrupt implementation that I mentioned
>> in the cover letter.
>>
>> On 11/10/21 17:56, Luca Ceresoli wrote:
>>> The RTC included in the MAX77714 PMIC is very similar to the one in the
>>> MAX77686. Reuse the rtc-max77686.c driver with the minimum required changes
>>> for the MAX77714 RTC.
>>>
>>> Signed-off-by: Luca Ceresoli <luca@...aceresoli.net>
>>> ---
>>> drivers/rtc/Kconfig | 2 +-
>>> drivers/rtc/rtc-max77686.c | 24 ++++++++++++++++++++++++
>>> 2 files changed, 25 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
>>> index e1bc5214494e..a73591ad292b 100644
>>> --- a/drivers/rtc/Kconfig
>>> +++ b/drivers/rtc/Kconfig
>>> @@ -375,7 +375,7 @@ config RTC_DRV_MAX8997
>>>
>>> config RTC_DRV_MAX77686
>>> tristate "Maxim MAX77686"
>>> - depends on MFD_MAX77686 || MFD_MAX77620 || COMPILE_TEST
>>> + depends on MFD_MAX77686 || MFD_MAX77620 || MFD_MAX77714 || COMPILE_TEST
>>> help
>>> If you say yes here you will get support for the
>>> RTC of Maxim MAX77686/MAX77620/MAX77802 PMIC.
>>> diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
>>> index 9901c596998a..e6564bc2171e 100644
>>> --- a/drivers/rtc/rtc-max77686.c
>>> +++ b/drivers/rtc/rtc-max77686.c
>>> @@ -19,6 +19,7 @@
>>>
>>> #define MAX77686_I2C_ADDR_RTC (0x0C >> 1)
>>> #define MAX77620_I2C_ADDR_RTC 0x68
>>> +#define MAX77714_I2C_ADDR_RTC 0x48
>>> #define MAX77686_INVALID_I2C_ADDR (-1)
>>>
>>> /* Define non existing register */
>>> @@ -203,6 +204,28 @@ static const struct max77686_rtc_driver_data max77686_drv_data = {
>>> .regmap_config = &max77686_rtc_regmap_config,
>>> };
>>>
>>> +static const struct regmap_irq_chip max77714_rtc_irq_chip = {
>>> + .name = "max77714-rtc",
>>> + .status_base = MAX77686_RTC_INT,
>>> + .mask_base = MAX77686_RTC_INTM,
>>> + .num_regs = 1,
>>> + .irqs = max77686_rtc_irqs,
>>> + .num_irqs = ARRAY_SIZE(max77686_rtc_irqs) - 1, /* no WTSR on 77714 */
>>> +};
>>> +
>>> +static const struct max77686_rtc_driver_data max77714_drv_data = {
>>> + .delay = 16000,
>>> + .mask = 0x7f,
>>> + .map = max77686_map,
>>> + .alarm_enable_reg = false,
>>> + .rtc_irq_from_platform = false,
>>
>> As far as I could understand, rtc_irq_from_platform should be 'true'.
>> This would trigger the 'if' branch in function
>> max77686_init_rtc_regmap() [0]:
>>
>> if (info->drv_data->rtc_irq_from_platform) {
>> struct platform_device *pdev = to_platform_device(info->dev);
>>
>> info->rtc_irq = platform_get_irq(pdev, 0);
>> if (info->rtc_irq < 0)
>> return info->rtc_irq;
>> } else {
>> info->rtc_irq = parent_i2c->irq;
>> }
>>
>> Calling platform_get_irq() seems correct for the MAX77714, which can
>> generate various IRQ events, collecting them in a register, and raise a
>> single IRQ to the CPU via a physical pin.
>>
>> However, if I set rtc_irq_from_platform = true, platform_get_irq()
>> returns IRQ number '1', which ends up in:
>>
>> dummy 0-0048: Failed to request IRQ 1 for max77714-rtc: -22
>> max77686-rtc max77714-rtc: Failed to add RTC irq chip: -22
>> max77686-rtc: probe of max77714-rtc failed with error -22
>>
>> I compared my code with other MFD drivers and their cell drivers (but
>> their datasheets is not available so I had to add some guesswork), and
>> couldn't find out where my code is wrong.
>>
>> Unfortunately I have no IRQ access on my board (and I don't need them
>> for my use case). For this reason I initially thought of disabling all
>> the IRQ code in rtc-max77686.c via a new flag, but it would be quite
>> invasive and I wouldn't even be able to test that existing hardware
>> still works. Implementing a new RTC driver for the MAX77714 does not
>> seem to be a sane option as the hardware is really 99% equal to the
>> MAX77686 RTC.
>>
>
> I think the flag should be false, not true. The true means you have RTC
> device with its own interrupt. For example in DT it could look like:
>
> pmic@1c {
> compatible = "maxim,max77714";
> reg = <0x1c>;
> interrupt-parent = <&gpio2>;
> interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
>
> interrupt-controller;
> #interrupt-cells = <2>;
> };
>
> rtc@48 {
> compatible = "maxim,max77714-rtc";
> reg = <0x48>;
> interrupt-parent = <&gpio2>;
> interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> };
>
> In your case, the RTC device will not have its own devicetree node and
> will be instantiated as MFD child device. The only interrupt line
> available is the parents interrupt line - the same as in max77686 and
> max77802 setups.
>
> Have in mind that this does not necessarily reflect real HW, but how we
> represent it in devicetree and driver model.
Good to know. Thank you for the explanation.
--
Luca
Powered by blists - more mailing lists