Reply-To: <bhuvanchandra.dv@toradex.com>
Subject: Re: [RFC 1/2] spi: spidev: Use 'new_id' sysfs file for enabling
 spidev
References: <1460978308-8062-1-git-send-email-bhuvanchandra.dv@toradex.com>
 <1460978308-8062-2-git-send-email-bhuvanchandra.dv@toradex.com>
 <20160418130126.GC3217@sirena.org.uk>
To: Mark Brown <broonie@kernel.org>
CC: <gregkh@linuxfoundation.org>, <stefan@agner.ch>,
        <linux-kernel@vger.kernel.org>, <linux-spi@vger.kernel.org>,
        Stefan Agner <stefan.agner@toradex.com>,
        Bhuvanchandra <bhuvanchandra.dv@toradex.com>
From: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Organization: Toradex
Message-ID: <5717726C.2090302@toradex.com>
Date: Wed, 20 Apr 2016 17:43:32 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160418130126.GC3217@sirena.org.uk>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2016 12:13:59.5075 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR05MB269
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1292
Lines: 33

On 04/18/2016 06:31 PM, Mark Brown wrote:
> On Mon, Apr 18, 2016 at 04:48:27PM +0530, Bhuvanchandra DV wrote:
>
>> +++ b/Documentation/ABI/testing/sysfs-bus-spi-spidev
>> @@ -0,0 +1,8 @@
>> +What:		/sys/bus/spi/drivers/spidev/new_id
>> +Date:		March 2016
>> +Description:
>> +		This allows to load spidev at runtime. new_id file accepts bus
>> +		number and chip select in 'B.C' format.
>> +		e.g.
>> +		To load spidev1.1 at runtime:
>> +		$ echo 1.1 > /sys/bus/spi/drivers/spidev/new_id
>
> I would expect a new_id file to allow a new device identifier to be
> added to a driver at runtime but this isn't doing that, it's specifying
> by bus and chip select instead which is totally different to how we
> normally bind SPI devices.  That seems likely to cause confusion down
> the line.  I'd expect to be able to supply a DT compatible string or a
> Linux SPI ID.

SPI drivers bind to the device as configured in DT, but in case of 
spidev(non DT approach) the device is not available in hand to bind the 
driver. So tried this approach of creating the device and then bind 
spidev. I agree this is not a standard way we bind SPI devices. With out 
a device available, seems it is not possible to bind spidev in non DT 
approach. Please correct me if i'm wrong.

>

-- 
Best regards,
Bhuvan