From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B96BAC47088 for ; Fri, 2 Dec 2022 12:22:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:Subject:From:References:Cc:To: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=miUiTF2mO1BzAXc1SmKiuNTvcH0sPjaAaSx/WdmKm7c=; b=CVpacnzzzU9Bj3 43JLsn8DipilFsBJoN+ED0QIN4XY+5CiznnfrZTq6UhRBghndQXYlJPtx/+XYxralhBz+n/OuJMuo OSJ1R97mQjibbaHKWIRi3iopdk6u/cSLyZYkGwAqxcrYleeeY4OgJxQiFwHOhpy3wvVtco6CwuH+5 OBifySEtrU8kAH8H1I4rzAkNBFuoOAm9Pk2c4LSv/Dc05ZVMFxSEm6BZsEmhApCqsabRcCndy3hhH Dgyqk5L6MpL9lWLnDdbG427nAx1+iaXPJjPWo++p4U3n8XLj1voHahzojIKEMAFK6YvLHsDZNs1mu VHVQ4qoaHk17rVvp4f/w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p152y-00GIW2-2c; Fri, 02 Dec 2022 12:21:40 +0000 Received: from mga09.intel.com ([134.134.136.24]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p152t-00GIUX-2u for linux-arm-kernel@lists.infradead.org; Fri, 02 Dec 2022 12:21:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669983695; x=1701519695; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=RCNCqkazhFBYrQaykaK4k78oh0l+6rQ5XaKkf5iBXLo=; b=lJLQNoKgQb7t90dZnpohgE47mZy7o404sgQnsmkBTjTCkYsGUmV2u1jk Rinm2jASRom8qZT/jpW/TjUh+6f6my6asu6wlXN0l3JEqhAraCqTd1wQV Z5qF+1S+eFzYPfCT/EZMibk0gU2FOFSl40MDFw496YU0+KenF8eeevbKL Uo242lO4YX+5pHSELmiCm/00AxM+9MxnvmFCX9R9eyXCF56Jzj5cUS+fZ 4c09+g1XWuePDm3fuQOh58T/3M/hvH1e4ANC3wCIfnDEwpyhQNOJoLhct /j7haVglHw7IbSRv9vDFmmWKun9+uIkh6dmZzMnSpoCezkQfSQjrchFq3 g==; X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="317091096" X-IronPort-AV: E=Sophos;i="5.96,212,1665471600"; d="scan'208";a="317091096" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 04:21:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="645012213" X-IronPort-AV: E=Sophos;i="5.96,212,1665471600"; d="scan'208";a="645012213" Received: from mattu-haswell.fi.intel.com (HELO [10.237.72.199]) ([10.237.72.199]) by orsmga002.jf.intel.com with ESMTP; 02 Dec 2022 04:21:23 -0800 Message-ID: Date: Fri, 2 Dec 2022 14:22:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.4.2 To: Arnd Bergmann , Greg Kroah-Hartman , Daehwan Jung Cc: Rob Herring , Krzysztof Kozlowski , Alim Akhtar , Mathias Nyman , Linus Walleij , Colin Ian King , Artur Bujdoso , Juergen Gross , Tomer Maimon , "open list:USB SUBSYSTEM" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "moderated list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES" , "open list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES" , open list , sc.suh@samsung.com, taehyun.cho@samsung.com, jh0801.jung@samsung.com, eomji.oh@samsung.com References: <1669860811-171746-1-git-send-email-dh10.jung@samsung.com> <1669860811-171746-3-git-send-email-dh10.jung@samsung.com> Content-Language: en-US From: Mathias Nyman Subject: Re: [RFC PATCH v1 2/2] usb: host: add xhci-exynos to support Exynos SOCs In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221202_042135_226751_1118973B X-CRM114-Status: GOOD ( 25.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 1.12.2022 11.01, Arnd Bergmann wrote: > On Thu, Dec 1, 2022, at 09:06, Greg Kroah-Hartman wrote: >> On Thu, Dec 01, 2022 at 11:13:31AM +0900, Daehwan Jung wrote: >>> This driver works with xhci platform driver. It needs to override >>> functions of xhci_plat_hc_driver. Wakelocks are used for sleep/wakeup >>> scenario of system. >> >> So this means that no other platform xhci driver can be supported in the >> same system at the same time. >> >> Which kind of makes sense as that's not anything a normal system would >> have, BUT it feels very odd. This whole idea of "override the platform >> driver" feels fragile, why not make these just real platform drivers and >> have the xhci platform code be a library that the other ones can use? >> That way you have more control overall, right? Agree that overriding the generic platform driver xhci_hc_platform_driver from this exynos driver is odd. But I don't understand how this works. Where are the hcds created and added when this xhci-exonys driver binds to the device? all this driver does in probe is the overriding? Am I missing something here? > > Agreed, having another layer here (hcd -> xhci -> xhcd_platform -> > xhcd_exynos) would fit perfectly well into how other SoC specific > drivers are abstracted. This could potentially also help reduce > the amount of code duplication between other soc specific variants > (mtk, tegra, mvebu, ...) that are all platform drivers but don't > share code with xhci-plat.c. > > Alternatively, it seems that all of the xhci-exynos support could > just be part of the generic xhci-platform driver: as far as I can > tell, none of the added code is exynos specific at all, instead it > is a generic xhci that is using the wakeup_source framework. Sounds reasonable as well, and if some exynos specific code is needed then just create a xhci_plat_priv struct for exynos and pass it in of_device_id data like other vendors that use the generic xhci-platform driver do. -Mathias _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel