From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752380AbcGAS5d (ORCPT ); Fri, 1 Jul 2016 14:57:33 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:35390 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751036AbcGAS5b (ORCPT ); Fri, 1 Jul 2016 14:57:31 -0400 MIME-Version: 1.0 In-Reply-To: <20160701162228.GZ6247@sirena.org.uk> References: <20160628183825.GS17217@sirena.org.uk> <20160628205736.GE17217@sirena.org.uk> <20160629180211.GF6247@sirena.org.uk> <20160701082548.GE6247@sirena.org.uk> <20160701150015.GQ6247@sirena.org.uk> <20160701162228.GZ6247@sirena.org.uk> From: Michal Suchanek Date: Fri, 1 Jul 2016 20:56:44 +0200 Message-ID: Subject: Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver To: Mark Brown Cc: Greg Kroah-Hartman , Linux Kernel Mailing List , linux-spi Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1 July 2016 at 18:22, Mark Brown wrote: > On Fri, Jul 01, 2016 at 05:37:53PM +0200, Michal Suchanek wrote: > >> Can you, please, specify what problems this patch creates for other users >> and maintainability? > > To repeat yet again a major design goal for DT is to describe the > hardware rather than implementation details of the software you plan to > run on the system. Not doing this breaks upgrades or changes in our > ideas of how we control a given bit of hardware. > >> Without stating the problems of this solution clearly or proposing alternate >> workable solution there is not much that can be done. > > You are rejecting out of hand any suggestion that is not the one > solution you are demanding. Your only suggestion is that hardware that is not driven by kernel is described to the kernel. I have written in great detail why this does not make sense. So to me it seems that you reject out of hand any suggestion that is not the one solution you are demanding. You have not raised any concrete reason against the proposed solution other than it does not describe the hardware. The hardware cannot be described for practical usability reasons. > > I'm done with this thread, please come back with new code that fits in > with the device model and device tree designs. Is there any solution that fits the driver model and allows using spidev with arbitrary device without describing said device in devicetree? Thanks Michal From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Suchanek Subject: Re: [PATCH v2 3/3] drivers core: allow id match override when manually binding driver Date: Fri, 1 Jul 2016 20:56:44 +0200 Message-ID: References: <20160628183825.GS17217@sirena.org.uk> <20160628205736.GE17217@sirena.org.uk> <20160629180211.GF6247@sirena.org.uk> <20160701082548.GE6247@sirena.org.uk> <20160701150015.GQ6247@sirena.org.uk> <20160701162228.GZ6247@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Greg Kroah-Hartman , Linux Kernel Mailing List , linux-spi To: Mark Brown Return-path: In-Reply-To: <20160701162228.GZ6247-GFdadSzt00ze9xe1eoZjHA@public.gmane.org> Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: On 1 July 2016 at 18:22, Mark Brown wrote: > On Fri, Jul 01, 2016 at 05:37:53PM +0200, Michal Suchanek wrote: > >> Can you, please, specify what problems this patch creates for other users >> and maintainability? > > To repeat yet again a major design goal for DT is to describe the > hardware rather than implementation details of the software you plan to > run on the system. Not doing this breaks upgrades or changes in our > ideas of how we control a given bit of hardware. > >> Without stating the problems of this solution clearly or proposing alternate >> workable solution there is not much that can be done. > > You are rejecting out of hand any suggestion that is not the one > solution you are demanding. Your only suggestion is that hardware that is not driven by kernel is described to the kernel. I have written in great detail why this does not make sense. So to me it seems that you reject out of hand any suggestion that is not the one solution you are demanding. You have not raised any concrete reason against the proposed solution other than it does not describe the hardware. The hardware cannot be described for practical usability reasons. > > I'm done with this thread, please come back with new code that fits in > with the device model and device tree designs. Is there any solution that fits the driver model and allows using spidev with arbitrary device without describing said device in devicetree? Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html