From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.codeaurora.org by pdx-caf-mail.web.codeaurora.org (Dovecot) with LMTP id jWshF0yaHls4WwAAmS7hNA ; Mon, 11 Jun 2018 15:52:38 +0000 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id ABC9A608D2; Mon, 11 Jun 2018 15:52:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by smtp.codeaurora.org (Postfix) with ESMTP id E1F6E600D0; Mon, 11 Jun 2018 15:52:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org E1F6E600D0 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=holtmann.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932258AbeFKPwg convert rfc822-to-8bit (ORCPT + 20 others); Mon, 11 Jun 2018 11:52:36 -0400 Received: from coyote.holtmann.net ([212.227.132.17]:32927 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750928AbeFKPwe (ORCPT ); Mon, 11 Jun 2018 11:52:34 -0400 Received: from marcel-macpro.fritz.box (p5B3D24B5.dip0.t-ipconnect.de [91.61.36.181]) by mail.holtmann.org (Postfix) with ESMTPSA id 24B88CF186; Mon, 11 Jun 2018 17:59:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: [PATCH v2 15/24] net: qualcomm: MODULE_DEVICE_TABLE(serdev) From: Marcel Holtmann In-Reply-To: Date: Mon, 11 Jun 2018 17:52:31 +0200 Cc: LKML , "open list:SERIAL DRIVERS" , Lino Sanfilippo , "David S. Miller" , Stefan Wahren , Rob Herring , Johan Hovold , netdev@vger.kernel.org Content-Transfer-Encoding: 8BIT Message-Id: <07871EF5-D1D3-4677-8100-B5E7F14DB302@holtmann.org> References: <20180611115240.32606-1-ricardo.ribalda@gmail.com> <20180611115240.32606-16-ricardo.ribalda@gmail.com> To: Ricardo Ribalda Delgado X-Mailer: Apple Mail (2.3445.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ricardo, >>>> the commit message is misleading me. If I build something with ACPI or DT support, then modinfo will show all modalias information for ACPI and DT compatible strings. What else does udev/modprobe actually need? Is something broken with the modalias export? >>> >>> The main purpose is to autoload drivers for devices that have been >>> created via sysfs or another module. >>> >>> Eg1: We have a serial port on a standard computer that has connected a >>> GPS module. Since it is something that is not in the ACPI nor the DT >>> table the user will run >>> >>> echo serdev_gps > /sys/bus/serial/devices/serial0/new_device >>> >>> Eg2 module: https://github.com/ribalda/linux/blob/415bb3f0076c2b846ebe5409589b8e1e3004f55a/drivers/tty/serdev/test_platform.c >>> >>> Modprobe does not know what module to load for that device unless >>> there is a matching MODULE_DEVICE_TABLE >>> Today, we have the same functionality for i2c devices >>> https://www.kernel.org/doc/Documentation/i2c/instantiating-devices >> >> but why does this have to be the driver name? I would rather say, create a generic string that describes the hardware and then use that. I think you also want the special handling, as from USB for example, that lets you reference an existing .compatible or ACPI ID as reference so that the driver_data is copied. > > We can choose any name, but if there are no special variants (like the > rave-sp driver) I would prefer using the module name. We can of course > use more names, like the part number of the the device, but it is very > convenient to also use the module name, and other subsystems also do > that. > > If you want to add specific names for this device please let me know > and I will add them to the list. You know much more about this module > than myself. if we want to use the driver name, then why not build this into the new_device handling itself instead of duplicating that name in each serdev_device_id table. What is the reference here? For example platform device do matching on driver name if I recall this correctly. However what is most important is that device_get_match_data() actually works. There should be no difference between DT, ACPI or a dynamic device. Regards Marcel