Received: by 10.223.185.116 with SMTP id b49csp4665930wrg; Mon, 26 Feb 2018 23:58:44 -0800 (PST) X-Google-Smtp-Source: AH8x226BALSdD3D5KvbmMFALU1wWV9kTODq82CID2T7gnHBF0BD1Bicky0x9nmUptamRlX2l+a6C X-Received: by 10.99.67.133 with SMTP id q127mr10776599pga.365.1519718324592; Mon, 26 Feb 2018 23:58:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519718324; cv=none; d=google.com; s=arc-20160816; b=XtArQbZIVuPTpc6+LKtkbdWaiP/FrSlX7q/Icty/mlm5LjZvr+HmkFp//YcGRheKTK zUQd0WJx84A0dm+Nh3LNt0viRAFku2sAkTnKrztyCha5QCIvDoU5ILzM21iE1Gedl/jV cu3HLKLmYmhGKti5o48Ac0Vgumq+wtysT0efuZyCgVdVdfolULLC7La94eWQoMtddOwE gooOcHqFtn6cVaob4yec5h2Chn9BVTrQwmL0jrQQfWFSac/R7qpk8OJNpqhe7Mn9jiq1 dd7d2JmX9//1+x962Z1Uv1fpunlMmzuQM5u1UCDq3kElxuLVq3yKHn9h1uYTZSy7ESf0 rbRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature:arc-authentication-results; bh=UDCFhsKIZB2zKSXKze8mHTxDGOF6cWL64G29bvg/15s=; b=mmmh+bk/DmdAuEMl6VSoIpD+7CEPmUKXiyCI6ek4Pdimhw44BaGl/xHzkUpVABWNNE g+J5cr6l67AD/NLvoYk+SX6uqdF3BRx5DjzRHS4fQfiPMCqgyZEkQZ+fdlpG2CWtg1i4 7RKiYj4yro+9L4KASVRykBYL+clQ6KTwypuYUeKfEq8k3v4Pj4nbiVc45lb/XeL7jPBT 30q1b+j3NCNBZHSveL0OyJaHZMlmVdZwD/MKsDMTYviOFEmiA4yMO5IyxuKZug0TwT82 K41CdC7Y5Eh/lzH37aa7YWU5v/e2Kaov/sjMmtSOiRxQtwb5WWbGxCM+asue3ihhvd6N m1qg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@goldelico.com header.s=strato-dkim-0002 header.b=LtQ5hxZI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h12-v6si828796pls.270.2018.02.26.23.58.29; Mon, 26 Feb 2018 23:58:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@goldelico.com header.s=strato-dkim-0002 header.b=LtQ5hxZI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752503AbeB0Hdx (ORCPT + 99 others); Tue, 27 Feb 2018 02:33:53 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.219]:21519 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752149AbeB0Hdv (ORCPT ); Tue, 27 Feb 2018 02:33:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1519716829; s=strato-dkim-0002; d=goldelico.com; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH; bh=UDCFhsKIZB2zKSXKze8mHTxDGOF6cWL64G29bvg/15s=; b=LtQ5hxZINxICWdj51DAB6GKrv1sNqr9NORImv/2v6ojqgEb32VLliPq6fHKDKZienR MMZ25wW9KVoVjPVNoqmWIpYtwA0k6qDBAHm7vvDFlcRDZ+j+ZvbOR/lmoj1u2I601qz+ +xvzGBusMM7d6D4BkvNdc7cX7gvdbQqFaYLXL3ies7KxDHwyeNrmr9/gZODQ9QNuUpsR uYmT6/UfKpT+BK2g+TiHJspW5R+AdGnoHeRJeMS//n2Vu1LpcW6fOxH8/KtDfBUtje69 eeTKQsMUrimq0nE2m/Bp2TRFM3j/FNPOU62yQ7d2GxPgS7aMl8hdg7WrW45gFQU2BshR fcAg== X-RZG-AUTH: :JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBj4Qpw87WisdNwE1M= X-RZG-CLASS-ID: mo00 Received: from [192.168.2.107] (p57AE092B.dip0.t-ipconnect.de [87.174.9.43]) by smtp.strato.de (RZmta 42.18 DYNA|AUTH) with ESMTPSA id L0b6e6u1R7Wp5B3 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Tue, 27 Feb 2018 08:32:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver From: "H. Nikolaus Schaller" In-Reply-To: <20180227070415.GB18666@localhost> Date: Tue, 27 Feb 2018 08:32:50 +0100 Cc: Pavel Machek , Mark Rutland , DTML , Thierry Reding , Jonathan Cameron , Arnd Bergmann , Tony Lindgren , Greg Kroah-Hartman , Russell King , Linux Kernel Mailing List , Rob Herring , Kevin Hilman , =?utf-8?Q?Beno=C3=AEt_Cousson?= , kernel@pyra-handheld.com, Discussions about the Letux Kernel , linux-omap , =?utf-8?Q?Andreas_F=C3=A4rber?= , Linux ARM Content-Transfer-Encoding: 7bit Message-Id: <22A8F5FE-C8B9-46EB-B98D-A94EA4170131@goldelico.com> References: <5494ad34b39a6c62601e3747440268dfb3be7d5a.1512114576.git.hns@goldelico.com> <20171222124427.GI3374@localhost> <91850CC3-B280-4701-9D07-96AFF3A79A6F@goldelico.com> <90F9A8E4-035A-4A9E-8AAB-757491D63E69@goldelico.com> <20180112153903.GB5992@localhost> <20180212152618.GC13962@amd> <20180227070415.GB18666@localhost> To: Johan Hovold X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Johan, > Am 27.02.2018 um 08:04 schrieb Johan Hovold : > > On Mon, Feb 12, 2018 at 04:26:18PM +0100, Pavel Machek wrote: >> Hi! >> >>>> Let's restart this discussion and focus on the main roadblock (others >>>> are minor details which can be sorted out later). >>>> >>>> If it feels like a hack, the key issue seems to me to be the choice of >>>> the API to present the GPS data to user space. Right? >>> >>> Or even more fundamentally, does this belong in the kernel at all? >> >> Yes, it does. Thanks, Pavel for supporting our view. > > But not necessarily in its current form. Is this a "yes after some code fixes"? Pavel mentioned an example where such an evolutionary approach was taken. > >>> Now, if we'd ever have a proper GPS framework that handled everything in >>> kernel space (i.e. no more gpsd) then we would be able to write kernel >>> drivers that also take care of PM. But perhaps that's unlikely to ever >>> be realised given the state of things (proprietary protocols, numerous >>> quirky implementations, etc). >> >> That is what needs to happen. >> >>> The kernel is probably not the place to be working around issues like >>> that, even if serdev at least allows for such hacks to be fairly >>> isolated in drivers (unlike some of the earlier proposals touching core >>> code). >> >> Oh, kernel is indeed right place to provide hardware abstraction -- >> and that includes bug workarounds. > > Right, at least when such hacks can be confined to a driver and not be > spread all over the place. It seems that you forgot that the driver we propose is not spread all over the place. It *is* confined to a single driver thanks to the serdev api. BR and thanks, Nikolaus