linux-kernel - Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55E742FC.3020109@ti.com>
Date:	Wed, 2 Sep 2015 14:42:04 -0400
From:	Murali Karicheri <m-karicheri2@...com>
To:	santosh shilimkar <santosh.shilimkar@...cle.com>,
	"Kwok, WingMan" <w-kwok2@...com>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"pawel.moll@....com" <pawel.moll@....com>,
	"mark.rutland@....com" <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ssantosh@...nel.org" <ssantosh@...nel.org>
Subject: Re: [PATCH] ARM: dts: keystone: use one to one address translations
 under netcp

On 09/02/2015 02:25 PM, santosh shilimkar wrote:
> 9/2/2015 10:58 AM, Murali Karicheri wrote:
>> On 09/02/2015 01:24 PM, santosh shilimkar wrote:
>>> On 9/2/2015 9:35 AM, Murali Karicheri wrote:
>>>> Santosh,
>>>>
>>
>> ---Cut-------------------
>>
>>>>> 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.
>>>>
>>>> Using Phy interface is not acceptable to the subsystem maintainer based
>>>> on the communication I had on this. Also the Phy here is tighly coupled
>>>> with the hardware block it is working with. So this model is not right
>>>> for SerDes driver as it require additional enhancements as described
>>>> below if needs to be used.
>>>>
>>> Thanks for update on that.
>>>
>>>> The serdes initialization procedure requires checking the status in the
>>>> hardware block (PCIe, 1G or 10G) and then taking corrective action.
>>>> This
>>>> means a Phy driver would require mapping of related hw address space
>>>> (PCIe, 1G and 10G) as well which is already mapped by the hardware
>>>> driver(PCIe, 1G and 10G). One solution is to treat this as a libray
>>>> function that can be called from the respective hardware device driver.
>>>>   A device node of h/w device (PCIe or 1G) in such as looks like
>>>>
>>> Or SerDes driver can embed the status reg address space.
>>> This is read only access so should be fine.
>>>
>>>> pcie {
>>>>
>>>>      serdes@...eaddress {
>>>>          reg = <address of serdes>;
>>>>      }
>>>> }
>>>>
>>>> hw driver will call ks2_serdes_init(node, hw_base_address) to
>>>> initialize
>>>> the serdes. Other APIs can be added to enable/disable lane or shutdown
>>>> etc. The libary will be added to drivers/soc/ti/ and used by various
>>>> device drivers to initialize and use the phy. As the serdes is slightly
>>>> integrated with the hardware block, IMO, this is a better approach than
>>>> using the phy model. The API definitions will be added to
>>>> include/linux/soc/ti/ folder.
>>>>
>>> Serdes Driver with its status register address space might solve this
>>> sharing problem. Library might work but we should try to have driver
>>> considering there is a physical device. I don't have strong opinion
>>> on drivers vs library.
>>>
>>
>> In addition to checking status in the SerDes, it needs to also check the
>> status of the associated hardware block (PCIe, 1G, 10G etc). So this
>> means, same needs to be mapped twice, first by the above hardware device
>> drivers and then by the serdes driver which causes problem. My point is
>> since they both are tightly coupled, a libary is a better option. That
>> way the mapped address can be passed to the serdes API to perform the
>> required task, instead of using Phy API which doesn't allow us to do the
>> same. If SerDes h/w can be brought up independently, the Phy model fits
>> well.
>>
> As I said, I don't have strong preference and fine with library approach.
> I suggest you do a RFC to take this further. Include Arnd on CC for
> that.

Sure!

Murali
>
> Regards,
> Santosh
>
>
>
>


-- 
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/