Maybe you can tell why you want to add this to kernel and what file you are changing.
Also, please share the kernel log, the software release version, devkit or custom board?
Please learn to describe more about your issue instead of only sharing one picture.
Btw, adding this to the kernel is only needed for some kind of automatic driver loading or quirk handling. What is the actual device in each case? I see vendor ID 0x1286 for Marvell Semiconductor, but 0x23cc is not a known vendor. If you happen to have a new product from vendor ID 0x23cc, then you could customize for this, but in reality you would probably be better off using udev to set this up. “Quirks” might be an exception where you want the device to adjust for some non-compliant behavior, but then you’d probably still want to add udev rules to handle this. No matter what you should provide details on what the two devices are and what it is you want to accomplish (and the log and other info mentioned by @WayneWWW).
Uploading: image.png… Use 32.5 version, custom version, BSP based on Jetson development
Wait a moment, I will upload the kernel information
If you want to add a 4G communication module to Jetson, you can use the normal Linux kernel. Why does Jetson have no response
Sorry, I’m not sure what the question means. I understand the part of adding a 4G module, but I have to guess at the rest.
What is the exact model of this module, and how is it connected? I am thinking via m.2 slot, but something like m.2 actually has more than one interface, e.g., it might be USB or PCIe. Many more details would be required to even begin to answer.
Any interface which is “hot plug” (which includes USB, and so long as it is present upon boot, also includes PCIe) identifies a device by means of the device itself responding to a query. This is typically what the manufacturer and product ID combination is for. If that combination is in the database, and if that database associates a driver, then this is when the driver takes over and loads (you could say hot plug layers advertise new devices, and drivers which believe they can handle the device take ownership).
In the case of ID not being in the database it is up to the end user to install a driver. Typically the steps to install the driver also provide the association to the ID, but at times one would also edit a conf file (not needed very often).
RF devices (which 4G devices are an example of) are highly regulated by law, and this complicates the above. Manufacturers could create different designs which are shipped only to particular regions of the world, but this is expensive. Instead most such devices have “firmware” which can upload into the device itself, and that firmware completes the device to make it usable (following the laws of that region of the world). If this device uses external firmware, then it will never be recognized and will never be visible for driver load unless the firmware loads. In such a case the steps to install the driver from the manufacturer typically also installs the firmware. The end user usually does not note any difference, but if the driver were already present and known to the system, then a device without firmware would mysteriously fail to load the driver as if no driver is present. There is a strong chance that your device requires both a third party driver and firmware, but the first step is to identify the driver.
You’ll find you don’t need to modify the kernel unless you are authoring the driver. If specifications of the device model are provided, then an internet search may identify a Linux driver. That driver (for a custom device with regulatory needs) is likely from the manufacturer. You might find the kernel can have a module for the hardware added directly from the existing kernel source, but the firmware itself tends to be both regulatory and proprietary, so often the firmware must come from the manufacturer (the Linux kernel might have the driver or might not, but it is unlikely the Linux kernel itself would ever ship with the firmware…firmware is not part of the kernel).
In the case of a USB device you can see the USB hot plug has done its job if you see it via “lsusb”. Similarly for PCI with “lspci”, although there are a few conditions in which it might not show up even if PCI is running correctly. More information is needed on the device.
The model is me909s-805p. Its predecessor is 909s-821. Huawei’s module 821 can be used directly because it was added before, and the hardware has not been changed
Just one statement for this issue:
If lsusb can detect this device, then the rest of work is from the vendor driver.
You didn’t upload any useful log, so we have nothing to share here.
Unfortunately the only web pages I could find for that exact model were non-English…and sadly that’s all I know. I did see references though to firmware, so it does seem this is something requiring a firmware download and not just a driver download. As mentioned by @WayneWWW, so long as the device is visible with either lsusb or lspci (depending on whether it uses USB lanes or PCIe lanes), then the rest is downloading the software from the vendor (there is no need to change the kernel, the kernel already found the device, but needs firmware and driver from the vendor).
Now is unable to find the device, but he and 821 pin is the same, this is why
909s-821 plug in or directly recognize lsusb
If plug in is recognized by lsusb, then it means everything in the kernel is working as expected. The next task is to hand over to a driver. Either a driver is not found, or else firmware needs to be loaded into the device before a driver is able to recognize the device (firmware basically changes what the device is). Does the manufacturer provide Linux firmware and/or drivers?