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: <0b97cacd-9bf4-135a-b2ee-1d51ab380b1c@broadcom.com>
Date:   Mon, 1 Apr 2019 14:43:17 -0700
From:   Ray Jui <ray.jui@...adcom.com>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>, linux-i2c@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org,
        bcm-kernel-feedback-list@...adcom.com,
        Rayagonda Kokatanur <rayagonda.kokatanur@...adcom.com>
Subject: Re: [PATCH v5 6/8] dt-bindings: i2c: iproc: add "brcm,iproc-nic-i2c"
 compatible string

Hi Wolfram,

On 3/27/2019 3:24 PM, Wolfram Sang wrote:
> 
>> Update iProc I2C binding document to add new compatible string
>> "brcm,iproc-nic-i2c". Optional property "brcm,ape-hsls-addr-mask" is
>> also added that allows configuration of the host view into the APE's
>> address for "brcm,iproc-nic-i2c"
> 
> I don't know the platform, but wouldn't it be more DT-like to describe
> the APE in DT and derive the mask from that information? Custom bindings
> with values which are directly poked into a register usually raise my
> eyebrow.
> 

Note APE is a co-processor that is not visible from the Linux running
from the host processor.

"brcm,iproc-nic-i2c" here is introduced to allow the I2C port from APE
to be completely owned by the host CPU, to meet the requirement of
certain use cases. At the same time, the control of the I2C port from
APE will be disabled.

The "brcm,ape-hsls-addr-mask" defines the address translation and be
programmed into some configuration registers to allow the host to
directly access the I2C registers of APE. Note those configuration
registers are owned by the host, and that address is not APE's address
space nor the host is intending to take over the control of APE.

Therefore, I think it makes way more sense to use an address mask type
of DT property here.

Thanks,

Ray

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ