From: "James Tai [戴志峰]" <james.tai@realtek.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <maz@kernel.org>, "Rob Herring" <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
kernel test robot <lkp@intel.com>,
Dan Carpenter <error27@gmail.com>
Subject: RE: [PATCH v3 2/6] irqchip: Add interrupt controller support for Realtek DHC SoCs
Date: Tue, 19 Dec 2023 03:15:52 +0000 [thread overview]
Message-ID: <d9556a14e8d64f83b89a2d1d231003f4@realtek.com> (raw)
In-Reply-To: <87cyvgsocp.ffs@tglx>
Hi Thomas,
>On Wed, Nov 29 2023 at 13:43, James Tai wrote:
>> Realtek DHC (Digital Home Center) SoCs share a common interrupt
>> controller design. This universal interrupt controller driver provides
>> support for various variants within the Realtek DHC SoC family.
>>
>> Each DHC SoC features two sets of extended interrupt controllers, each
>> capable of handling up to 32 interrupts. These expansion controllers
>> are connected to the GIC (Generic Interrupt Controller).
>>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Reported-by: Dan Carpenter <error27@gmail.com>
>> Closes: https://lore.kernel.org/r/202311201929.2FpvMRlg-lkp@intel.com/
>
>These tags are pointless as they are not related to anything in tree. You
>addressed review comments and 0-day fallout, but neither Dan nor 0-day
>reported that the interrupt controller for Realtek DHC SoCs is missing.
>
I will remove it.
>> +#include "irq-realtek-intc-common.h"
>> +
>> +struct realtek_intc_data;
>
>struct realtek_intc_data is declared in irq-realtek-intc-common.h, so what's the
>point of this forward declaration?
>
This is a meaningless declaration, and I will remove it.
>> +static inline unsigned int realtek_intc_get_ints(struct
>> +realtek_intc_data *data) {
>> + return readl(data->base + data->info->isr_offset); }
>> +
>> +static inline void realtek_intc_clear_ints_bit(struct
>> +realtek_intc_data *data, int bit) {
>> + writel(BIT(bit) & ~1, data->base + data->info->isr_offset);
>
>That '& ~1' solves what aside of preventing bit 0 from being written?
>
The ISR register uses bit 0 to clear or set ISR status.
Write 0 to clear bits and write 1 to set bits.
Therefore, to clear the interrupt status, bit 0 should consistently be set to '0'.
>> +static int realtek_intc_domain_map(struct irq_domain *d, unsigned int
>> +irq, irq_hw_number_t hw) {
>> + struct realtek_intc_data *data = d->host_data;
>> +
>> + irq_set_chip_and_handler(irq, &realtek_intc_chip, handle_level_irq);
>> + irq_set_chip_data(irq, data);
>> + irq_set_probe(irq);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct irq_domain_ops realtek_intc_domain_ops = {
>> + .xlate = irq_domain_xlate_onecell,
>> + .map = realtek_intc_domain_map,
>
> .xlate = irq_domain_xlate_onecell,
> .map = realtek_intc_domain_map,
>
>Please.
>
I will fix it.
>> +};
>> +
>> +static int realtek_intc_subset(struct device_node *node, struct
>> +realtek_intc_data *data, int index) {
>> + struct realtek_intc_subset_data *subset_data =
>&data->subset_data[index];
>> + const struct realtek_intc_subset_cfg *cfg = &data->info->cfg[index];
>> + int irq;
>> +
>> + irq = irq_of_parse_and_map(node, index);
>
>irq_of_parse_and_map() returns an 'unsigned int' where 0 is fail.
>
I will use of_irq_get() instead.
>> + if (irq <= 0)
>> + return irq;
>> +
>> + subset_data->common = data;
>> + subset_data->cfg = cfg;
>> + subset_data->parent_irq = irq;
>> + irq_set_chained_handler_and_data(irq, realtek_intc_handler,
>> + subset_data);
>> +
>> + return 0;
>> +}
>> +
>> +int realtek_intc_probe(struct platform_device *pdev, const struct
>> +realtek_intc_info *info) {
>> + struct realtek_intc_data *data;
>> + struct device *dev = &pdev->dev;
>> + struct device_node *node = dev->of_node;
>> + int ret, i;
>> +
>> + data = devm_kzalloc(dev, struct_size(data, subset_data,
>info->cfg_num), GFP_KERNEL);
>> + if (!data)
>> + return -ENOMEM;
>> +
>> + data->base = of_iomap(node, 0);
>> + if (!data->base) {
>> + ret = -ENOMEM;
>> + goto out_cleanup;
>
>devm_kzalloc() is automatically cleaned up when the probe function fails, so
>'return -ENOMEM;' is sufficient.
I will adjust it.
>
>> + }
>> +
>> + data->info = info;
>> +
>> + raw_spin_lock_init(&data->lock);
>> +
>> + data->domain = irq_domain_add_linear(node, 32,
>&realtek_intc_domain_ops, data);
>> + if (!data->domain) {
>> + ret = -ENOMEM;
>
>This 'ret = -ENOMEM;' is pointless as the only error code returned in this
>function is -ENOMEM. So you can just return -ENOMEM in the error path, no?
>
Yes. it is pointless and I will adjust it.
>> + goto out_cleanup;
>> + }
>> +
>> + data->subset_data_num = info->cfg_num;
>> + for (i = 0; i < info->cfg_num; i++) {
>> + ret = realtek_intc_subset(node, data, i);
>> + if (ret) {
>> + WARN(ret, "failed to init subset %d: %d", i, ret);
>> + ret = -ENOMEM;
>> + goto out_cleanup;
>
> if (WARN(ret, "....."))
> goto cleanup;
>
I will fix it.
>> + }
>> + }
>> +
>> + platform_set_drvdata(pdev, data);
>> +
>> + return 0;
>> +
>> +out_cleanup:
>> +
>> + if (data->base)
>> + iounmap(data->base);
>
>Leaks the irqdomain.
>
I will add error handle for irqdomain.
>> +
>> + devm_kfree(dev, data);
>
>Pointless exercise.
>
I will remove it.
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(realtek_intc_probe);
>
>EXPORT_SYMBOL_GPL
>
I will fix it.
>> +/**
>> + * realtek_intc_subset_cfg - subset interrupt mask
>> + * @ints_mask: inetrrupt mask
>> + */
>> +struct realtek_intc_subset_cfg {
>> + unsigned int ints_mask;
>> +};
>
>The value of a struct wrapping a single 'unsigned int' is? What's wrong with
>using unsigned int (actually you want u32 as this represents a hardware mask)
>directly? Not enough obfuscation, right?
>
Yes, it represents a set of hardware masks, so using u32 instead of 'unsigned int' is more appropriate.
There are no issues with obfuscation.
>> +/**
>> + * realtek_intc_info - interrupt controller data.
>> + * @isr_offset: interrupt status register offset.
>> + * @umsk_isr_offset: unmask interrupt status register offset.
>> + * @scpu_int_en_offset: interrupt enable register offset.
>> + * @cfg: cfg of the subset.
>> + * @cfg_num: number of cfg.
>
> * @isr_offset: interrupt status register offset
> * @umsk_isr_offset: unmask interrupt status register offset
> * @scpu_int_en_offset: interrupt enable register offset
>
>Can you spot the difference?
>
The interrupt control registers of the DHC platform are not linearly arranged, which necessitates the use of a mechanism for efficient reading and writing of these registers.
The 'scpu_int_en' register serves the purpose of controlling whether peripheral devices' interrupts are enabled or disabled.
The 'isr' register represents the interrupt status. It can mask interrupts using the 'scpu_int_en' register. When the 'scpu_int_en' register disables interrupts, the 'isr' register will not reflect the interrupt status.
The 'umsk_isr' register also represents the interrupt status but is not influenced by any other control register to mask interrupts. In short, it reflects the original interrupt status.
>Please fix all over the place.
>
I will fix it.
>> + */
>> +struct realtek_intc_info {
>> + const struct realtek_intc_subset_cfg *cfg;
>> + unsigned int isr_offset;
>> + unsigned int umsk_isr_offset;
>> + unsigned int scpu_int_en_offset;
>> + const u32
>*isr_to_scpu_int_en_mask;
>> + int cfg_num;
>> +};
>> +
>> +/**
>> + * realtek_intc_subset_data - handler of a interrupt source only handles ints
>> + * bits in the mask.
>> + * @cfg: cfg of the subset.
>
>Seriously. 'cfg of'? This is a description, so can you spell the words out? This is
>really neither space constraint nor subject to Xitter rules. Fix this all over the
>place please.
I will adjust the description so that it clearly describes the intended purpose.
>
>> + * @common: common data.
>> + * @parent_irq: interrupt source.
>> + */
>> +struct realtek_intc_subset_data {
>> + const struct realtek_intc_subset_cfg *cfg;
>> + struct realtek_intc_data *common;
>> + int parent_irq;
>> +};
>> +
>> +/**
>> + * realtek_intc_data - configuration data for realtek interrupt controller
>driver.
>> + * @base: base of interrupt register
>> + * @info: info of intc
>> + * @domain: interrupt domain
>> + * @lock: lock
>> + * @saved_en: status of interrupt enable
>> + * @subset_data_num: number of subset data
>> + * @subset_data: subset data
>> + */
>> +struct realtek_intc_data {
>> + void __iomem *base;
>> + const struct realtek_intc_info *info;
>> + struct irq_domain *domain;
>> + struct raw_spinlock lock;
>> + unsigned int saved_en;
>> + int subset_data_num;
>> + struct realtek_intc_subset_data subset_data[]; };
>> +
>> +#define IRQ_ALWAYS_ENABLED U32_MAX
>> +#define DISABLE_INTC (0)
>> +#define CLEAN_INTC_STATUS GENMASK(31, 1)
>
>#define IRQ_ALWAYS_ENABLED U32_MAX
>#define DISABLE_INTC (0)
>#define CLEAN_INTC_STATUS GENMASK(31, 1)
>
>Please, as that makes this readable.
>
I will improve it.
Thanks for your feedback.
Regards,
James
next prev parent reply other threads:[~2023-12-19 3:16 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-29 5:43 [PATCH v3 0/6] Initial support for the Realtek DHC SoCs James Tai
2023-11-29 5:43 ` [PATCH v3 1/6] dt-bindings: interrupt-controller: Add support for " James Tai
2023-11-29 8:57 ` Krzysztof Kozlowski
2023-12-08 5:40 ` James Tai [戴志峰]
2023-11-29 5:43 ` [PATCH v3 2/6] irqchip: Add interrupt controller " James Tai
2023-11-29 8:21 ` Dan Carpenter
2023-11-29 13:21 ` Dan Carpenter
2023-12-08 8:21 ` James Tai [戴志峰]
2023-12-08 8:43 ` Dan Carpenter
2023-12-11 5:19 ` James Tai [戴志峰]
2023-11-29 15:41 ` Rob Herring
2023-12-11 5:19 ` James Tai [戴志峰]
2023-12-08 15:31 ` Thomas Gleixner
2023-12-19 3:15 ` James Tai [戴志峰] [this message]
2023-12-20 15:30 ` Thomas Gleixner
2023-12-22 6:20 ` James Tai [戴志峰]
2023-11-29 5:43 ` [PATCH v3 3/6] irqchip: Introduce RTD1319 support using the Realtek common interrupt controller driver James Tai
2023-12-08 15:37 ` Thomas Gleixner
2023-12-19 5:51 ` James Tai [戴志峰]
2023-12-11 17:41 ` Rob Herring
2023-12-19 5:10 ` James Tai [戴志峰]
2023-11-29 5:43 ` [PATCH v3 4/6] irqchip: Introduce RTD1319D " James Tai
2023-11-29 5:43 ` [PATCH v3 5/6] irqchip: Introduce RTD1325 " James Tai
2023-11-29 5:43 ` [PATCH v3 6/6] irqchip: Introduce RTD1619B " James Tai
2023-12-08 15:41 ` Thomas Gleixner
2023-12-19 3:29 ` James Tai [戴志峰]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d9556a14e8d64f83b89a2d1d231003f4@realtek.com \
--to=james.tai@realtek.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=error27@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=maz@kernel.org \
--cc=robh+dt@kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).