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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 9 Aug 2020 10:44:07 +0200
From:   Krzysztof Kozlowski <>
To:     Arnd Bergmann <>
Cc:     Felipe Balbi <>,
        "" <>,
        Russell King <>,
        Greg Kroah-Hartman <>,
        Linux ARM <>,
        USB list <>
Subject: Re: [PATCH v2 09/41] usb: gadget: s3c-hsudc: remove platform header

On Fri, Aug 07, 2020 at 07:42:30PM +0200, Arnd Bergmann wrote:
> On Fri, Aug 7, 2020 at 3:59 PM Felipe Balbi <> wrote:
> > Krzysztof Kozlowski <> 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.

All this is a work on a very old SoC with an unknown number of
current/real users. I don't have the hardware to test so I would prefer
to skip any big changes. As Arnd suggests, we could just drop this one
board and the driver... or if it does not harm/bother to much we could
keep it as is, just without platform header dependency. Someone still
might be using it.

Best regards,

Powered by blists - more mailing lists