From: kernel test robot <lkp@intel.com>
To: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>, ioana.ciornei@nxp.com
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>,
Dan Carpenter <error27@gmail.com>, Su Hui <suhui@nfschina.com>
Subject: Re: [PATCH] bus: fsl-mc: fix an error handling in fsl_mc_device_add()
Date: Tue, 23 Dec 2025 23:23:01 +0800 [thread overview]
Message-ID: <202512232341.mNsrluKO-lkp@intel.com> (raw)
In-Reply-To: <20251222074958.992911-1-lihaoxiang@isrc.iscas.ac.cn>
Hi Haoxiang,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.19-rc2 next-20251219]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Haoxiang-Li/bus-fsl-mc-fix-an-error-handling-in-fsl_mc_device_add/20251222-155324
base: linus/master
patch link: https://lore.kernel.org/r/20251222074958.992911-1-lihaoxiang%40isrc.iscas.ac.cn
patch subject: [PATCH] bus: fsl-mc: fix an error handling in fsl_mc_device_add()
config: x86_64-buildonly-randconfig-001-20251223 (https://download.01.org/0day-ci/archive/20251223/202512232341.mNsrluKO-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251223/202512232341.mNsrluKO-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512232341.mNsrluKO-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/bus/fsl-mc/fsl-mc-bus.c:899:27: error: expected ';' after expression
899 | put_device(&mc_dev->dev)
| ^
| ;
1 error generated.
vim +899 drivers/bus/fsl-mc/fsl-mc-bus.c
778
779 /*
780 * Add a newly discovered fsl-mc device to be visible in Linux
781 */
782 int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
783 struct fsl_mc_io *mc_io,
784 struct device *parent_dev,
785 struct fsl_mc_device **new_mc_dev)
786 {
787 int error;
788 struct fsl_mc_device *mc_dev = NULL;
789 struct fsl_mc_bus *mc_bus = NULL;
790 struct fsl_mc_device *parent_mc_dev;
791
792 if (dev_is_fsl_mc(parent_dev))
793 parent_mc_dev = to_fsl_mc_device(parent_dev);
794 else
795 parent_mc_dev = NULL;
796
797 if (strcmp(obj_desc->type, "dprc") == 0) {
798 /*
799 * Allocate an MC bus device object:
800 */
801 mc_bus = kzalloc(sizeof(*mc_bus), GFP_KERNEL);
802 if (!mc_bus)
803 return -ENOMEM;
804
805 mutex_init(&mc_bus->scan_mutex);
806 mc_dev = &mc_bus->mc_dev;
807 } else {
808 /*
809 * Allocate a regular fsl_mc_device object:
810 */
811 mc_dev = kzalloc(sizeof(*mc_dev), GFP_KERNEL);
812 if (!mc_dev)
813 return -ENOMEM;
814 }
815
816 mc_dev->obj_desc = *obj_desc;
817 mc_dev->mc_io = mc_io;
818 device_initialize(&mc_dev->dev);
819 mc_dev->dev.parent = parent_dev;
820 mc_dev->dev.bus = &fsl_mc_bus_type;
821 mc_dev->dev.release = fsl_mc_device_release;
822 mc_dev->dev.type = fsl_mc_get_device_type(obj_desc->type);
823 if (!mc_dev->dev.type) {
824 error = -ENODEV;
825 dev_err(parent_dev, "unknown device type %s\n", obj_desc->type);
826 goto error_cleanup_dev;
827 }
828 dev_set_name(&mc_dev->dev, "%s.%d", obj_desc->type, obj_desc->id);
829
830 if (strcmp(obj_desc->type, "dprc") == 0) {
831 struct fsl_mc_io *mc_io2;
832
833 mc_dev->flags |= FSL_MC_IS_DPRC;
834
835 /*
836 * To get the DPRC's ICID, we need to open the DPRC
837 * in get_dprc_icid(). For child DPRCs, we do so using the
838 * parent DPRC's MC portal instead of the child DPRC's MC
839 * portal, in case the child DPRC is already opened with
840 * its own portal (e.g., the DPRC used by AIOP).
841 *
842 * NOTE: There cannot be more than one active open for a
843 * given MC object, using the same MC portal.
844 */
845 if (parent_mc_dev) {
846 /*
847 * device being added is a child DPRC device
848 */
849 mc_io2 = parent_mc_dev->mc_io;
850 } else {
851 /*
852 * device being added is the root DPRC device
853 */
854 if (!mc_io) {
855 error = -EINVAL;
856 goto error_cleanup_dev;
857 }
858
859 mc_io2 = mc_io;
860 }
861
862 error = get_dprc_icid(mc_io2, obj_desc->id, &mc_dev->icid);
863 if (error < 0)
864 goto error_cleanup_dev;
865 } else {
866 /*
867 * A non-DPRC object has to be a child of a DPRC, use the
868 * parent's ICID and interrupt domain.
869 */
870 mc_dev->icid = parent_mc_dev->icid;
871 mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
872 mc_dev->dev.dma_mask = &mc_dev->dma_mask;
873 mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
874 dev_set_msi_domain(&mc_dev->dev,
875 dev_get_msi_domain(&parent_mc_dev->dev));
876 }
877
878 /*
879 * Get MMIO regions for the device from the MC:
880 *
881 * NOTE: the root DPRC is a special case as its MMIO region is
882 * obtained from the device tree
883 */
884 if (parent_mc_dev && obj_desc->region_count != 0) {
885 error = fsl_mc_device_get_mmio_regions(mc_dev,
886 parent_mc_dev);
887 if (error < 0)
888 goto error_cleanup_dev;
889 }
890
891 /*
892 * The device-specific probe callback will get invoked by device_add()
893 */
894 error = device_add(&mc_dev->dev);
895 if (error < 0) {
896 dev_err(parent_dev,
897 "device_add() failed for device %s: %d\n",
898 dev_name(&mc_dev->dev), error);
> 899 put_device(&mc_dev->dev)
900 return error;
901 }
902
903 dev_dbg(parent_dev, "added %s\n", dev_name(&mc_dev->dev));
904
905 *new_mc_dev = mc_dev;
906 return 0;
907
908 error_cleanup_dev:
909 kfree(mc_dev->regions);
910 if (mc_bus)
911 kfree(mc_bus);
912 else
913 kfree(mc_dev);
914
915 return error;
916 }
917 EXPORT_SYMBOL_GPL(fsl_mc_device_add);
918
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2025-12-23 15:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-22 7:49 [PATCH] bus: fsl-mc: fix an error handling in fsl_mc_device_add() Haoxiang Li
2025-12-22 23:13 ` kernel test robot
2025-12-23 15:23 ` kernel test robot [this message]
2025-12-23 15:34 ` Christophe Leroy (CS GROUP)
2025-12-24 7:54 ` Dan Carpenter
2025-12-24 9:57 ` Christophe Leroy (CS GROUP)
2025-12-24 10:52 ` Haoxiang Li
2025-12-24 11:07 ` Christophe Leroy (CS GROUP)
2025-12-24 11:26 ` Haoxiang Li
2025-12-26 9:39 ` Dan Carpenter
2025-12-26 9:35 ` Dan Carpenter
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=202512232341.mNsrluKO-lkp@intel.com \
--to=lkp@intel.com \
--cc=error27@gmail.com \
--cc=ioana.ciornei@nxp.com \
--cc=lihaoxiang@isrc.iscas.ac.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=llvm@lists.linux.dev \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=suhui@nfschina.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.