Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753108AbbD2TZm (ORCPT ); Wed, 29 Apr 2015 15:25:42 -0400 Received: from mail-wg0-f46.google.com ([74.125.82.46]:34138 "EHLO mail-wg0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753023AbbD2TZi (ORCPT ); Wed, 29 Apr 2015 15:25:38 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150427173036.GA10950@lukather> <20150427180728.GW22845@sirena.org.uk> <20150428141630.GR22845@sirena.org.uk> <20150428171738.GY22845@sirena.org.uk> <20150429174059.GQ22845@sirena.org.uk> <20150429180659.GT22845@sirena.org.uk> From: Michal Suchanek Date: Wed, 29 Apr 2015 21:24:56 +0200 Message-ID: Subject: Re: [linux-sunxi] [PATCH 2/3] spidev: Add DT binding example. To: Geert Uytterhoeven Cc: Mark Brown , "Eric D." , linux-sunxi , Jonathan Corbet , Hans de Goede , Linux Kernel Mailing List , Maxime Ripard , linux-spi , Martin Sperl Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1629 Lines: 38 On 29 April 2015 at 20:56, Geert Uytterhoeven wrote: > On Wed, Apr 29, 2015 at 8:37 PM, Michal Suchanek wrote: >> I am using a version of Maxime's patch myself right now. It does not >> seem it's going to be include in the kernel any time soon, however. >> >> FWIW I added the ability to open any CS, even those claimed by kernel >> drivers. This addresses any potential race of spidev binding before >> the actual driver but has the potential to introduce some subtle bugs >> when you open and reconfigure a CS used by a kernel driver or send >> some commands that upset the device. > > Uh, that sounds dangerous. > > Perhaps you can add some safety net, before user space can access > them, cfr. /sys/class/gpio/export? > That's what accessing random devices from userspace is. I can issue the identify commead to my SPI flash allright since it is idle. I am not sure of its protocol details but I am quite sure that some displays have data transfers that allow pauses so if I sent a command during a screen update it would likely get inserted into the framebuffer bitstream. And changing CS polarity or something like that will certainly have interesting results. Still not binding spidev to busy CS is just one test that can be compiled in as an option. If things stay this simple I don't see much problem with that. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/