linux-kernel - Re: [alsa-devel] [Patch v6 1/7] slimbus: Device management on SLIMbus

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: <d68d2f4f-92d9-76a7-aea7-4c91924819f3@linaro.org>
Date:   Thu, 12 Oct 2017 14:26:42 +0100
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Sanyog Kale <sanyog.r.kale@...el.com>
Cc:     gregkh@...uxfoundation.org, broonie@...nel.org,
        alsa-devel@...a-project.org, mark.rutland@....com,
        michael.opdenacker@...e-electrons.com, poeschel@...onage.de,
        andreas.noever@...il.com, gong.chen@...ux.intel.com, arnd@...db.de,
        kheitke@...ience.com, bp@...e.de, devicetree@...r.kernel.org,
        james.hogan@...tec.com, pawel.moll@....com,
        linux-arm-msm@...r.kernel.org, sharon.dvir1@...l.huji.ac.il,
        robh+dt@...nel.org, sdharia@...eaurora.org, alan@...ux.intel.com,
        treding@...dia.com, mathieu.poirier@...aro.org, jkosina@...e.cz,
        linux-kernel@...r.kernel.org, daniel@...ll.ch, joe@...ches.com,
        davem@...emloft.net
Subject: Re: [alsa-devel] [Patch v6 1/7] slimbus: Device management on SLIMbus



On 12/10/17 12:01, Sanyog Kale wrote:
> On Fri, Oct 06, 2017 at 05:51:30PM +0200, srinivas.kandagatla@...aro.org wrote:
>> From: Sagar Dharia <sdharia@...eaurora.org>
>>
>> +Per specification, Slimbus uses "clock gears" to do power management based on
>> +current frequency and bandwidth requirements. There are 10 clock gears and each
>> +gear changes the Slimbus frequency to be twice its previous gear.
> 
> Does the spec mandate 10 clock gears or its controller property?

Clock Gear Construct is part of SLIMbus Specs to alter clk frequency.


>> +Device notifications to the driver:
>> +-----------------------------------
>> +Since SLIMbus devices have mechanisms for reporting their presence, the
>> +framework allows drivers to bind when corresponding devices report their
>> +presence on the bus.
>> +However, it is possible that the driver needs to be probed
>> +first so that it can enable corresponding SLIMbus devie (e.g. power it up and/or
>> +take it out of reset). To support that behavior, the framework allows drivers
>> +to probe first as well  (e.g. using standard DeviceTree compatbility field).
>> +This creates the necessity for the driver to know when the device is functional
>> +(i.e. reported present). device_up callback is used for that reason when the
>> +device reports present and is assigned a logical address by the controller.
>> +
>> +Similarly, SLIMbus devices 'report absent' when they go down. A 'device_down'
>> +callback notifies the driver when the device reports absent and its logical
>> +address assignment is invalidated by the controller.
> 
> Is the same logical address assign when it reports present again?

Currently, Code as it is will pick the first available logical address. 
If required we can add logic in future to assign same logical address.
For now the code is simple.



>> + *
>> + *	Controller here performs duties of the manager device, and 'interface
>> + *	device'. Interface device is responsible for monitoring the bus and
>> + *	reporting information such as loss-of-synchronization, data
>> + *	slot-collision.
>> + * @dev: Device interface to this driver
>> + * @nr: Board-specific number identifier for this controller/bus
>> + * @list: Link with other slimbus controllers
>> + * @name: Name for this controller
>> + * @min_cg: Minimum clock gear supported by this controller (default value: 1)
>> + * @max_cg: Maximum clock gear supported by this controller (default value: 10)
>> + * @clkgear: Current clock gear in which this bus is running
>> + * @a_framer: Active framer which is clocking the bus managed by this controller
>> + * @m_ctrl: Mutex protecting controller data structures
>> + * @addrt: Logical address table
>> + * @num_dev: Number of active slimbus slaves on this bus
>> + * @wq: Workqueue per controller used to notify devices when they report present
>> + * @xfer_msg: Transfer a message on this controller (this can be a broadcast
>> + *	control/status message like data channel setup, or a unicast message
>> + *	like value element read/write.
> 
> xfer_msg element is not present in structure.
> 

Thanks, it will be fixed in next version.

thanks,
Srini