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, 7 Aug 2020 19:42:30 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Felipe Balbi <balbi@...nel.org>
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Russell King <linux@...linux.org.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        USB list <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v2 09/41] usb: gadget: s3c-hsudc: remove platform header dependency

On Fri, Aug 7, 2020 at 3:59 PM Felipe Balbi <balbi@...nel.org> wrote:
> Krzysztof Kozlowski <krzk@...nel.org> writes:

> > +#include <linux/delay.h>
> > +
> >  #define S3C2443_CLKREG(x)            ((x) + S3C24XX_VA_CLKPWR)
> >
> >  #define S3C2443_PLLCON_MDIVSHIFT     16
> > @@ -184,5 +186,52 @@ s3c2443_get_epll(unsigned int pllval, unsigned int baseclk)
> >       return (unsigned int)fvco;
> >  }
> >
> > +static inline void s3c_hsudc_init_phy(void)
>
> This should, really, be a PHY driver under drivers/phy, since the goal
> is to make this platform-independent, might as well take the opportunity
> to introduce a proper driver, no?

In theory, this is absolutely correct. I fear it will be hard to find anyone
to make a larger scale cleanup of the file however. As my old changelog
text says, there is only one board (smdk2416) in the kernel that registers
the device. My change was the minimum to keep it working during the
move to a multiplatform configuration, but if there is someone who has
the hardware and volunteers to make a proper phy driver, that would also
work.

As the board only exists as a reference for other boards, but none of those
made it into the kernel, we could alternatively just decide to drop the
driver. There is also a .dts file for the board, which is lacking a device node
for the udc (and the driver lacks DT support), so that board file could also
be dropped then, leaving only the DT version as a reference for the SoC.

       Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ