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]
Date:   Mon, 3 Sep 2018 11:31:48 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Stefan Wahren <stefan.wahren@...e.com>,
        Guenter Roeck <linux@...ck-us.net>
Cc:     Rob Herring <robh+dt@...nel.org>, Eric Anholt <eric@...olt.net>,
        bcm-kernel-feedback-list@...adcom.com, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, serge@...pberrypi.org,
        linux-rpi-kernel@...ts.infradead.org,
        Mark Rutland <mark.rutland@....com>,
        Phil Elwell <phil@...pberrypi.org>,
        linux-hwmon@...r.kernel.org, Jean Delvare <jdelvare@...e.com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFC 0/2] hwmon: Add RPi PoE HAT fan driver



On 9/2/2018 10:13 AM, Stefan Wahren wrote:
> Hi Guenter,
> 
>> Guenter Roeck <linux@...ck-us.net> hat am 2. September 2018 um 18:49 geschrieben:
>>
>>
>> On 09/02/2018 09:26 AM, Stefan Wahren wrote:
>>> Hi Guenter,
>>>
>>>> Guenter Roeck <linux@...ck-us.net> hat am 2. September 2018 um 16:23 geschrieben:
>>>>
>>>>
>>>> On 09/02/2018 04:20 AM, Stefan Wahren wrote:
>>>>> This series is an early stage of the hwmon driver for the fan on the
>>>>> Raspberry Pi Power over Ethernet HAT [1]. At the end this should use a
>>>>> Device Tree Overlay.
>>>>>
>>>>> Changes by Stefan based on [2]:
>>>>> - reformat the downstream patches for submission
>>>>> - drop reboot notification
>>>>> - fix remaining checkpatch issues
>>>>> - add COMPILE_TEST to Kconfig
>>>>>
>>>>> The driver is mostly copy & paste from pwm-fan, which isn't good. Personally
>>>>> i see two options:
>>>>>
>>>>> 1) integrate the driver function into the pwm-fan driver (new compatible)
>>>>> 2) implement the core function as a PWM driver and use the pwm-fan driver on top
>>>>>
>>>>
>>>> I don't really see the point of thise driver. Why not implement either of those ?
>>>
>>> i'm not sure about your question. Since the fan is placed over the SoC, the fan should takes care of the SoC temperature. AFAIK the firmware should have exclusive access to the I2C. So why we need this mailbox interface instead of a I2C driver.
>>>
>>
>> The driver sets pwm values. The pwm-fan driver sets pwm values. A pwm driver
>> sets pwm values. The pwm-fan driver uses a pwm driver to set pwm values.
>> You appear to be arguing that the pwm-fan driver for Rpi is different than
>> a pwm-fan driver for all other hardware and should _not_ use a pwm driver
>> to set pwm values.
> 
> thanks for your explanation. Now i think i understand and sorry for the confusion. We need a driver which translate the pwm values into the mailbox properties. "My" RFC series is only a starting point (not intended for merge and not an option) for a discussion and i'm perfectly fine with 2).
> Both options would be feasible in general. I only wanted to know your opinion before i start to implement one of them.

Is not there a way to expose the PWM pins directly to the kernel instead 
of going through the firmware to do that for us? I am just asking 
because sometimes this appears to be possible, guess not in this case?
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ