From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932258AbbICOt4 (ORCPT ); Thu, 3 Sep 2015 10:49:56 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:42338 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754570AbbICOtx (ORCPT ); Thu, 3 Sep 2015 10:49:53 -0400 Message-ID: <55E85DD8.4070102@oracle.com> Date: Thu, 03 Sep 2015 07:48:56 -0700 From: "santosh.shilimkar@oracle.com" Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tony Lindgren CC: "Kwok, WingMan" , "robh+dt@kernel.org" , "pawel.moll@arm.com" , "mark.rutland@arm.com" , "ijc+devicetree@hellion.org.uk" , "galak@codeaurora.org" , "linux@arm.linux.org.uk" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "ssantosh@kernel.org" , "Karicheri, Muralidharan" Subject: Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp References: <1441139324-29296-1-git-send-email-w-kwok2@ti.com> <55E61658.9010207@oracle.com> <230CBA6E4B6B6B418E8730AC28E6FC7E04221776@DFLE11.ent.ti.com> <55E71AB3.7070406@oracle.com> <20150903142645.GS4215@atomide.com> In-Reply-To: <20150903142645.GS4215@atomide.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/3/15 7:26 AM, Tony Lindgren wrote: > * santosh shilimkar [150902 08:55]: >> >> I suspected the same. I know back then we started with SERDES code >> with NETCP but as you already know, its a separate block which >> is needed for NIC card to work. Its more of phy and hence its >> having different address space is not surprising. > > The point Santosh is making here though is that any drivers > tinkering with registers belonging to a separate hardware block > is a recipe for a long term maintenance nightmare with mysterious > bugs popping up as things are not clocked or powered properly > or become racy with other drivers. > > Each hardware block needs to have it's own driver and then the > drivers can communicate using some Linux generic APIs like clock, > regulator, phy, or mailbox frameworks. > Right !! Regards, Santosh