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:   Fri, 15 Dec 2017 14:55:04 -0600
From:   Rob Herring <robh@...nel.org>
To:     Chunfeng Yun <chunfeng.yun@...iatek.com>
Cc:     Felipe Balbi <felipe.balbi@...ux.intel.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Mark Rutland <mark.rutland@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Jean Delvare <jdelvare@...e.de>,
        Sean Wang <sean.wang@...iatek.com>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 0/7] Add USB remote wakeup driver

On Sat, Dec 09, 2017 at 04:45:29PM +0800, Chunfeng Yun wrote:
>     These patches introduce the SSUSB and SPM glue layer driver which is
> used to support usb remote wakeup. Usually the glue layer is put into
> a system controller, such as PERICFG module.
>     The old way to support usb wakeup is put into SSUSB controller drivers,
> including xhci-mtk driver and mtu3 driver, but there are some problems:
>     1. can't disdinguish the relation between glue layer and SSUSB IP
>        when SoCs supports multi SSUSB IPs;
>     2. duplicated code for wakeup are put into both xhci-mtk and mtu3
>        drivers;
>     3. the glue layer may vary on different SoCs with SSUSB IP, and will
>        make SSUSB controller drivers complicated;
>     In order to resolve these problems, it's useful to make the glue layer
> transparent by extracting a seperated driver, meanwhile to reduce the
> duplicated code and simplify SSUSB controller drivers.

Both the driver and binding look overly complicated to me when it looks 
like you just have 2 versions of enable/disable functions which modify 
a single register. The complexity may be justified if this was a common 
binding and driver, but it is not.

You already have a phandle to the system controller. Can't you add cells 
to it to handle any differences between instances? That and SoC specific 
compatible strings should be enough to handle differences.

Rob

Powered by blists - more mailing lists