linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Victor Bravo <1905@spmblk.com>,
	Arend Van Spriel <arend.vanspriel@broadcom.com>,
	Franky Lin <franky.lin@broadcom.com>,
	Hante Meuleman <hante.meuleman@broadcom.com>,
	Chi-Hsien Lin <chi-hsien.lin@cypress.com>,
	Wright Feng <wright.feng@cypress.com>,
	"David S. Miller" <davem@davemloft.net>,
	linux-wireless@vger.kernel.org,
	brcm80211-dev-list.pdl@broadcom.com,
	brcm80211-dev-list@cypress.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] brcmfmac: sanitize DMI strings v2
Date: Mon, 06 May 2019 15:26:28 +0300	[thread overview]
Message-ID: <87d0kvvkej.fsf@codeaurora.org> (raw)
In-Reply-To: <fb07ae01-4cca-98e7-1c2d-dfdf44909900@redhat.com> (Hans de Goede's message of "Mon, 6 May 2019 12:34:17 +0200")

Hans de Goede <hdegoede@redhat.com> writes:

> If we're going to do some filtering, then I suggest we play it safe and also
> disallow other chars which may be used as a separator somewhere, specifically
> ':' and ','.
>
> Currently upstream linux-firmware has these files which rely on the DMI
> matching:
>
> brcmfmac4330-sdio.Prowise-PT301.txt
> brcmfmac43430-sdio.Hampoo-D2D3_Vi8A1.txt
> brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt
>
> The others are either part of the DMI override table for devices with unsuitable
> DMI strings like "Default String"; or are device-tree based.
>
> So as long as we don't break those 3 (or break the ONDA one but get a symlink
> in place) we can sanitize a bit more then just non-printable and '/'.
>
> Kalle, Arend, what is your opinion on this?
>
> Note I do not expect the ONDA V80 Plus to have a lot of Linux users,
> but it definitely has some.

To me having spaces in filenames is a bad idea, but on the other hand we
do have the "don't break existing setups" rule, so it's not so simple. I
vote for not allowing spaces, I think that's the best for the long run,
but don't know what Arend thinks.

Maybe we could do some kind of fallback mechanism, like first trying the
sanitised filename and if that's not found then we try the old filename
with spaces? And if that old filename works we print a big fat warning
that the user should update the file and that the old "filename with
spaces" support is going away soon?

-- 
Kalle Valo

  reply	other threads:[~2019-05-06 12:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-04 16:26 PROBLEM: brcmfmac's DMI-based fw file names break built-in fw loader Victor Bravo
2019-05-04 19:11 ` Arend Van Spriel
2019-05-04 19:44   ` Victor Bravo
2019-05-05  8:20     ` Arend Van Spriel
2019-05-05 14:36       ` Victor Bravo
2019-05-05 14:48       ` [PATCH RFC] brcmfmac: sanitize DMI strings Victor Bravo
2019-05-05 14:52         ` Victor Bravo
2019-05-05 15:03       ` [PATCH RFC] brcmfmac: sanitize DMI strings v2 Victor Bravo
2019-05-06  8:13         ` Hans de Goede
2019-05-06  8:42           ` Kalle Valo
2019-05-06  9:14             ` Victor Bravo
2019-05-06 12:29               ` Kalle Valo
2019-05-06 14:06                 ` Victor Bravo
2019-05-06  9:06           ` Victor Bravo
2019-05-06  9:33             ` Hans de Goede
2019-05-06 10:20               ` Victor Bravo
2019-05-06 10:34                 ` Hans de Goede
2019-05-06 12:26                   ` Kalle Valo [this message]
2019-05-06 15:24                     ` Victor Bravo
2019-05-06 16:05                       ` Hans de Goede
2019-05-06 19:30                         ` Arend Van Spriel
2019-05-07 15:38                           ` Hans de Goede
2019-05-13  9:21                             ` Arend Van Spriel
2019-05-06  8:44         ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d0kvvkej.fsf@codeaurora.org \
    --to=kvalo@codeaurora.org \
    --cc=1905@spmblk.com \
    --cc=arend.vanspriel@broadcom.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=brcm80211-dev-list@cypress.com \
    --cc=chi-hsien.lin@cypress.com \
    --cc=davem@davemloft.net \
    --cc=franky.lin@broadcom.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=wright.feng@cypress.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).