From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966230AbbJ3Wum (ORCPT ); Fri, 30 Oct 2015 18:50:42 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:61154 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965292AbbJ3Wuk (ORCPT ); Fri, 30 Oct 2015 18:50:40 -0400 From: Arnd Bergmann To: Timur Tabi Cc: Sinan Kaya , dmaengine@vger.kernel.org, cov@codeaurora.org, jcm@redhat.com, Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Vinod Koul , Dan Williams , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] dma: add Qualcomm Technologies HIDMA channel driver Date: Fri, 30 Oct 2015 23:50:20 +0100 Message-ID: <3785872.6m49nEREgo@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5633F0FD.7060506@codeaurora.org> References: <1446174501-8870-1-git-send-email-okaya@codeaurora.org> <4552697.VhjWnxQoIo@wuerfel> <5633F0FD.7060506@codeaurora.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:HfTVVlvRO9+zMyEz2iEIkqhgac++AkC5llob9hvea/K+CBYkmYY UVCAK28Nh+bZPloAT15g6mwB34GrrYwtMnLFPCK3/NpI3h+jwwGe1/uiJU10/2mws706+VJ KkpBYQjFBhjD7Sjz0JOw8SnUmEk70cYRwRg04P2kXeI7/1KAMYvvLchEdQezfm+9sB3MSzF GQ+GY5RikBUgtlrVvxjQQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:/EvT0qdnheY=:kzO7CIjdaQf+a7gYlg5gLF 1Cz3LwNq7I8JqOsgc7WJkL+evroW2MGBbvoIxOoDATH5rvIBLcrDyFhf/Yt2Q+t+GWsM0VDgN ND13Nl6dmYBP5GxAKaCJ9rVCzle5r+XIgbjwv9MGSBZJcxL5ds9IruvmHMtYEvbGQkvOeU/F9 lG9eKquV8tlCwtZdvmTSRaUl799iuPqy1XRQyY19baTtPAYlcNNeW/KjDrY0QaZ/jYMNMNzNh Uij1WHFcH/OpAqNJs15+VHLdIIhpYKFNTG8FvNq/rKLOp3JRnQg69dQyT0a2tWKoM/7xicLDq diNkKaKI4nepXFoIVIi2Emgxlq5T2MXusdSKItseuud+bWmas4o9nAnAN4zPRQ2XbUfaTVYwR IIE7sGFfWv3l1x0fKBtWOEm1GuFhOY3WXX2Yty2RgMJyBXNMT4mVcmy7s6r0CmJHTR7AtV14y 9uWVSR6Nt/ZghOXkXDYlqFI3OhKsGIJKDH6z472v2yva93gCluf0t0KCLI60ZumrYLoCeWQCp XlNTkVImkmkFPXyPPcpYl7xOetD15nVZqGQo7+y0O2BLkdXpPDjPKPBXxwEQMVoW12ZMy7Df8 L/hD30HX6d4jf5gF4eGRMWXVvIWcNwvKtkaQaGtgYPloxjlGQHdH0eoFtMiKvXLVVymz8/Jtq moB8LAdvDX+doCtPnjVEJ13X2ym+vWhzN3GQBYMyVKCUyOjf2PrPCa1xY9tqH1c89oTzNzCTk +o0II32PJrl9ZxhF Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 30 October 2015 17:36:45 Timur Tabi wrote: > On 10/30/2015 05:28 PM, Arnd Bergmann wrote: > >>> > >Why ENODEV? Could you make this handle restarted system calls? > >> > > >> >This is the self test code. It gets called from probe. If there is a > >> >problem with the device or system configuration, I don't want to enable > >> >this device. I can certainly return a different error code though. > >> >What's a good code? > > I see. probe() is not restartable, so it cannot be -ERESTARTSYS. > > > > Maybe better use wait_event_timeout and not handle the signals then. > > It will eventually time out if something goes wrong. > > What about -EPROBE_DEFER? Isn't that "restartable"? Granted, it's only > supposed to be used if the driver is dependent on another driver to > probe, so I'm not sure it applies here. If the self-test fails, then it > is possible that it could succeed later? No, this is different. The probe function can get called from all sorts of contexts (sys_init_module, device_create, deferred probing), and not all of them go back to user space when returning an error, so we cannot deliver a signal to the calling process this way. Arnd