Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: John Garry <john.garry@huawei.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Steven Price <steven.price@arm.com>,
	"harb@amperecomputing.com" <harb@amperecomputing.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Will Deacon <will@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 5/5] arm/arm64: smccc: Add ARCH_SOC_ID support
Date: Fri, 1 May 2020 17:05:21 +0100	[thread overview]
Message-ID: <20200501160521.GB24840@bogus> (raw)
In-Reply-To: <426ff8ab-9c13-4301-a91e-989c19c4ff58@huawei.com>

On Fri, May 01, 2020 at 04:25:27PM +0100, John Garry wrote:
> On 30/04/2020 12:48, Sudeep Holla wrote:
> > +static int __init smccc_soc_init(void)
> > +{
> > +	struct device *dev;
> > +	int ret, soc_id_rev;
> > +	struct arm_smccc_res res;
> > +	static char soc_id_str[8], soc_id_rev_str[12];
> > +
> > +	if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2)
> > +		return 0;
> > +
> > +	ret = smccc_soc_id_support_check();
> > +	if (ret)
> > +		return ret;
> > +
> > +	arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 0, &res);
> > +
> > +	ret = smccc_map_error_codes(res.a0);
> > +	if (ret)
> > +		return ret;
> > +
> > +	soc_id_version = res.a0;
> > +
> > +	arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 1, &res);
> > +
> > +	ret = smccc_map_error_codes(res.a0);
> > +	if (ret)
> > +		return ret;
> > +
> > +	soc_id_rev = res.a0;
> > +
> > +	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> > +	if (!soc_dev_attr)
> > +		return -ENOMEM;
> > +
> > +	sprintf(soc_id_str, "0x%04x", IMP_DEF_SOC_ID(soc_id_version));
> > +	sprintf(soc_id_rev_str, "0x%08x", soc_id_rev);
> > +
> > +	soc_dev_attr->soc_id = soc_id_str;
> > +	soc_dev_attr->revision = soc_id_rev_str;
> > +
> > +	soc_dev = soc_device_register(soc_dev_attr);
> > +	if (IS_ERR(soc_dev)) {
> > +		ret = PTR_ERR(soc_dev);
> > +		goto free_soc;
> > +	}
> > +
> > +	dev = soc_device_to_device(soc_dev);
> > +
>
> Just wondering, what about if the platform already had a SoC driver - now it
> could have another one, such that we may have multiple sysfs soc devices,
> right?
>

Yes I had a quick look at that.

1. Such platform has option not to implement this SOC_ID if it doesn't
   really require it.

2. If the firmware starts implementing it on some variants, then we can
   distinguish them with compatibles and blacklist them from the other
   SoC driver if having both is an issue

3. SoC bus layer supports adding multiple SoC ID driver and it may show
   up as /sys/devices/soc<n> which may or may not be fine. But this
   happens only if neither [1] nor [2] is done. I am happy to see if there's
   any solution for this. Any suggestions ?

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-05-01 16:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 11:48 [PATCH 0/5] arm/arm64: smccc: Add ARCH_SOC_ID support Sudeep Holla
2020-04-30 11:48 ` [PATCH 1/5] arm/arm64: smccc: Update link to latest SMCCC specification Sudeep Holla
2020-05-01 14:46   ` Steven Price
2020-04-30 11:48 ` [PATCH 2/5] arm/arm64: smccc: Add the definition for SMCCCv1.2 version/error codes Sudeep Holla
2020-05-01 14:46   ` Steven Price
2020-04-30 11:48 ` [PATCH 3/5] arm/arm64: smccc: Drop smccc_version enum and use ARM_SMCCC_VERSION_1_x instead Sudeep Holla
2020-05-01 14:48   ` Steven Price
2020-04-30 11:48 ` [PATCH 4/5] firmware: psci: Add function to fetch SMCCC version Sudeep Holla
2020-04-30 11:48 ` [PATCH 5/5] arm/arm64: smccc: Add ARCH_SOC_ID support Sudeep Holla
2020-05-01 15:07   ` Steven Price
2020-05-01 15:57     ` Sudeep Holla
2020-05-01 15:25   ` John Garry
2020-05-01 16:05     ` Sudeep Holla [this message]
2020-05-01 16:40       ` John Garry

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=20200501160521.GB24840@bogus \
    --to=sudeep.holla@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=harb@amperecomputing.com \
    --cc=john.garry@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=steven.price@arm.com \
    --cc=will@kernel.org \
    /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