Linux-mediatek Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Alexandre Mergnat <amergnat@baylibre.com>,
	Rob Herring <robh+dt@kernel.org>, Yong Wu <yong.wu@mediatek.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Will Deacon <will@kernel.org>, Joerg Roedel <joro@8bytes.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	Fabien Parent <fparent@baylibre.com>,
	Markus Schneider-Pargmann <msp@baylibre.com>,
	Amjad Ouled-Ameur <aouledameur@baylibre.com>,
	devicetree@vger.kernel.org, iommu@lists.linux.dev
Subject: Re: [PATCH v2 2/3] iommu/mediatek: add support for 6-bit encoded port IDs
Date: Thu, 6 Oct 2022 11:46:38 +0100	[thread overview]
Message-ID: <86084a28-be55-1c58-eace-1d73868c33dc@arm.com> (raw)
In-Reply-To: <7d37e6ae-0dca-e0ef-2841-298c1ba9784f@collabora.com>

On 2022-10-04 12:59, AngeloGioacchino Del Regno wrote:
> Il 04/10/22 12:01, Alexandre Mergnat ha scritto:
>> From: Fabien Parent <fparent@baylibre.com>
>>
>> Until now the port ID was always encoded as a 5-bit data. On MT8365,
>> the port ID is encoded as a 6-bit data. This requires to rework the
>> macros F_MMU_INT_ID_LARB_ID, and F_MMU_INT_ID_PORT_ID in order
>> to support 5-bit and 6-bit encoded port IDs.
>>
>> Signed-off-by: Fabien Parent <fparent@baylibre.com>
>> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
>> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
>> ---
>>   drivers/iommu/mtk_iommu.c | 24 ++++++++++++++++++++----
>>   1 file changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
>> index 5a4e00e4bbbc..a57ce509c8b5 100644
>> --- a/drivers/iommu/mtk_iommu.c
>> +++ b/drivers/iommu/mtk_iommu.c
>> @@ -108,8 +108,10 @@
>>   #define F_MMU_INT_ID_SUB_COMM_ID(a)        (((a) >> 7) & 0x3)
>>   #define F_MMU_INT_ID_COMM_ID_EXT(a)        (((a) >> 10) & 0x7)
>>   #define F_MMU_INT_ID_SUB_COMM_ID_EXT(a)        (((a) >> 7) & 0x7)
>> -#define F_MMU_INT_ID_LARB_ID(a)            (((a) >> 7) & 0x7)
>> -#define F_MMU_INT_ID_PORT_ID(a)            (((a) >> 2) & 0x1f)
>> +#define F_MMU_INT_ID_LARB_ID(a, int_id_port_width)    \
>> +                ((a) >> (((int_id_port_width) + 2) & 0x7))
>> +#define F_MMU_INT_ID_PORT_ID(a, int_id_port_width)    \
>> +                (((a) >> 2) & GENMASK((int_id_port_width) - 1, 0))
> 
> I can't think about any cleaner way than this one, but that's decreasing 
> human
> readability by "quite a bit".

In terms of readability, the best thing to do would be define separate 
macros for each register format and make the choice at the (single) 
callsite rather than hiding it in the macro. In fact we're already doing 
exactly that with the HAS_SUB_COMM_2BITS and HAS_SUB_COMM_3BITS flags 
right at the same point, so please follow that same pattern for consistency.

Thanks,
Robin.


  reply	other threads:[~2022-10-06 10:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-04 10:01 [PATCH v2 0/3] iommu/mediatek: Add mt8365 iommu support Alexandre Mergnat
2022-10-04 10:01 ` [PATCH v2 1/3] dt-bindings: iommu: mediatek: add binding documentation for MT8365 SoC Alexandre Mergnat
2022-10-04 12:01   ` AngeloGioacchino Del Regno
2022-10-06  9:29   ` Markus Schneider-Pargmann
2022-10-04 10:01 ` [PATCH v2 2/3] iommu/mediatek: add support for 6-bit encoded port IDs Alexandre Mergnat
2022-10-04 11:59   ` AngeloGioacchino Del Regno
2022-10-06 10:46     ` Robin Murphy [this message]
2022-10-04 10:01 ` [PATCH v2 3/3] iommu/mediatek: add support for MT8365 SoC Alexandre Mergnat
2022-10-04 12:00   ` AngeloGioacchino Del Regno

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=86084a28-be55-1c58-eace-1d73868c33dc@arm.com \
    --to=robin.murphy@arm.com \
    --cc=amergnat@baylibre.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=aouledameur@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fparent@baylibre.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=msp@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=will@kernel.org \
    --cc=yong.wu@mediatek.com \
    /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