Message-ID: <08655b2e-a8c3-4355-90c3-a96f303e0640@quicinc.com>
Date:   Wed, 23 Aug 2023 16:36:14 +0530
From:   Ninad Naik <quic_ninanaik@...cinc.com>
To:     Pavan Kondeti <quic_pkondeti@...cinc.com>
CC:     <agross@...nel.org>, <andersson@...nel.org>,
        <konrad.dybcio@...aro.org>, <psodagud@...cinc.com>,
        <quic_ppareek@...cinc.com>, <quic_kprasan@...cinc.com>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <kernel@...cinc.com>
Subject: Re: [RFC PATCH 1/1] soc: qcom: Add driver to read secondary
 bootloader (XBL) log

Hi Pavan,

On 8/22/2023 6:09 PM, Pavan Kondeti wrote:
> On Tue, Aug 22, 2023 at 05:45:12PM +0530, Ninad Naik wrote:
>> Qualcomm secondary bootloader (XBL) boot log holds information to
>> identify various firmware configuration currently set on the SoC.
>> The XBL log is stored in a predefined reserved memory region.
>>
>> This drivers provides a way to print XBL logs on the console. To
>> do so, it provides a debugfs entry which captures the logs stored
>> in this reserved memory region. This entry can now be used to read
>> and print the XBL logs to console.
>>
>> User can use the below command to print XBL log to console:
>>          cat /sys/kernel/debug/xbl_log
>>
>> Signed-off-by: Ninad Naik <quic_ninanaik@...cinc.com>
>> ---
> 
> For a single patch, cover letter may not be needed. The under cut
> portion (this area) of the patch can be used to present the additional
> details.
> 
Ack.
>>   drivers/soc/qcom/Kconfig        |  13 +++
>>   drivers/soc/qcom/Makefile       |   1 +
>>   drivers/soc/qcom/dump_xbl_log.c | 139 ++++++++++++++++++++++++++++++++
>>   3 files changed, 153 insertions(+)
>>   create mode 100644 drivers/soc/qcom/dump_xbl_log.c
>>
> 
> [...]
> 
>> +static int map_addr_range(struct device_node **parent, const char *name,
>> +			  struct xbl_log_data *xbl_data)
>> +{
>> +	struct device_node *node;
>> +	struct resource res;
>> +	int ret;
>> +
>> +	node = of_find_node_by_name(*parent, name);
>> +	if (!node)
>> +		return -ENODEV;
>> +
>> +	ret = of_address_to_resource(node, 0, &res);
>> +	if (ret) {
>> +		dev_err(xbl_data->dev, "Failed to parse memory region\n");
>> +		return ret;
>> +	}
>> +	of_node_put(node);
>> +
>> +	if (!resource_size(&res)) {
>> +		dev_err(xbl_data->dev, "Failed to parse memory region size\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	xbl_data->buf_size = resource_size(&res) - 1;
>> +	xbl_data->xbl_buf = devm_memremap(xbl_data->dev, res.start,
>> +					  xbl_data->buf_size, MEMREMAP_WB);
>> +	if (!xbl_data->xbl_buf) {
>> +		dev_err(xbl_data->dev, "%s: memory remap failed\n", name);
>> +		return -ENOMEM;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static int xbl_log_probe(struct platform_device *pdev)
>> +{
>> +	struct device *dev = &pdev->dev;
>> +	struct xbl_log_data *xbl_data;
>> +	struct device_node *parent;
>> +	int ret;
>> +
>> +	xbl_data = devm_kzalloc(dev, sizeof(*xbl_data), GFP_KERNEL);
>> +	if (!xbl_data)
>> +		return -ENOMEM;
>> +
>> +	xbl_data->dev = &pdev->dev;
>> +	platform_set_drvdata(pdev, xbl_data);
>> +
>> +	parent = of_find_node_by_path("/reserved-memory");
>> +	if (!parent) {
>> +		dev_err(xbl_data->dev, "reserved-memory node missing\n");
>> +		return -ENODEV;
>> +	}
>> +
> 
> You would need to present the Device Tree binding document for this. For
> ex: pls see
> Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml
> 
Ack. Will add a corresponding DT binding in the next version
>> +	ret = map_addr_range(&parent, "uefi-log", xbl_data);
>> +	if (ret)
>> +		goto put_node;
>> +
>> +	xbl_data->dbg_data.data = xbl_data->xbl_buf;
>> +	xbl_data->dbg_data.size = xbl_data->buf_size;
>> +	xbl_data->dbg_file = debugfs_create_blob("xbl_log", 0400, NULL,
>> +						 &xbl_data->dbg_data);
>> +	if (IS_ERR(xbl_data->dbg_file)) {
>> +		dev_err(xbl_data->dev, "failed to create debugfs entry\n");
>> +		ret = PTR_ERR(xbl_data->dbg_file);
>> +	}
>> +
>> +put_node:
>> +	of_node_put(parent);
>> +	return ret;
>> +}
>> +
>> +static int xbl_log_remove(struct platform_device *pdev)
>> +{
>> +	struct xbl_log_data *xbl_data = platform_get_drvdata(pdev);
>> +
>> +	debugfs_remove_recursive(xbl_data->dbg_file);
>> +	return 0;
>> +}
>> +
>> +static struct platform_driver xbl_log_driver = {
>> +	.probe = xbl_log_probe,
>> +	.remove = xbl_log_remove,
>> +	.driver = {
>> +		   .name = "xbl-log",
>> +		   },
>> +};
>> +
>> +static struct platform_device xbl_log_device = {
>> +	.name = "xbl-log",
>> +};
>> +
>> +static int __init xbl_log_init(void)
>> +{
>> +	int ret = 0;
>> +
>> +	ret = platform_driver_register(&xbl_log_driver);
>> +	if (!ret) {
>> +		ret = platform_device_register(&xbl_log_device);
>> +		if (ret)
>> +			platform_driver_unregister(&xbl_log_driver);
>> +	}
>> +	return ret;
>> +}
>> +
> 
> The platform device registration, the resource parsing can be completely
> avoided by adding your compatible entry to reserved_mem_matches
> structure defined in drivers/of/platform.c . There are some Qualcomm SoC
> devices also present in that list.
> 
Ack. So once the compatible entry is added to reserved_mem_matches 
structure here, a platform_device is created for this node to which this 
driver can bind to. Thank you for the suggestion, I'll make the 
necessary corrections in the next revision.

>> +static void __exit xbl_log_exit(void)
>> +{
>> +	platform_device_unregister(&xbl_log_device);
>> +	platform_driver_unregister(&xbl_log_driver);
>> +}
>> +
>> +module_init(xbl_log_init);
>> +module_exit(xbl_log_exit);
>> +
>> +MODULE_DESCRIPTION("Qualcomm Technologies, Inc. (QTI) XBL log driver");
>> +MODULE_LICENSE("GPL");
>> -- 
>> 2.41.0
>>
Thanks,
Ninad

Powered by blists - more mailing lists