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:   Wed, 26 Aug 2020 10:05:50 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Takashi Iwai <tiwai@...e.de>, Mark Brown <broonie@...nel.org>
Cc:     Guennadi Liakhovetski <guennadi.liakhovetski@...ux.intel.com>,
        alsa-devel@...a-project.org,
        Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        Hui Wang <hui.wang@...onical.com>, vkoul@...nel.org,
        srinivas.kandagatla@...aro.org,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        jank@...ence.com, slawomir.blauciak@...el.com,
        Bard liao <yung-chuan.liao@...ux.intel.com>,
        Rander Wang <rander.wang@...ux.intel.com>
Subject: Re: [PATCH 1/4] regmap: sdw: move to -EOPNOTSUPP




>>>> checkpatch is broken.
>>
>>> Heh, I'm not objecting it :)
>>
>>> OTOH, it's also true that ENOTSUPP is no good error code if returned
>>> to user-space.  Unfortunately many codes (including what I wrote) use
>>> this code mistakenly, and they can't be changed any longer...
>>
>> It's also used internally in various places without being returned to
>> userspace, that's what's going on here - the regmap core has some
>> specific checks for -ENOTSUPP.
> 
> Sure, for such an internal usage any code can be used.
> The question is a case like this -- where the return code might be
> carried to outside.  Though, looking through the grep output, all
> callers simply return -EINVAL for any errors, so it doesn't matter
> much for now.

I assumed this change to -EOPNOTSUPP reflected a consensus in 
kernel-land, it's obviously not the case. This patch was supposed to be 
a trivial clean-up...

So to be clear, what is the direction for existing code
a) keep -ENOTSUPP as is?
b) move to -EOPNOTSUPP?

And what is the preference for new code?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ