On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
>
> Several of them were due to the process of converting files from
> DocBook, LaTeX, HTML and Markdown. They were probably introduced
> by the conversion tools used
On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> This patch series is doing conversion only when using ASCII makes
> more sense than using UTF-8.
>
> See, a number of converted documents ended with weird characters
> like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specifi
On Tue, 2021-05-11 at 11:00 +0200, Mauro Carvalho Chehab wrote:
> Yet, this series has two positive side effects:
>
> - it helps people needing to touch the documents using non-utf8 locales[1];
> - it makes easier to grep for a text;
>
> [1] There are still some widely used distros nowadays (LT
Your title 'Use ASCII subset' is now at least a bit *closer* to
describing what the patches are actually doing, but it's still a bit
misleading because you're only doing it for *some* characters.
And the wording is still indicative of a fundamentally *misguided*
motivation for doing any of this. Y
On Wed, 2021-05-12 at 17:17 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 10:14:44 -0400
> "Theodore Ts'o" escreveu:
>
> > On Wed, May 12, 2021 at 02:50:04PM +0200, Mauro Carvalho Chehab wrote:
> > > v2:
> > > - removed EM/EN DASH conversion from this patchset;
> >
> > Are you stil
On Fri, 2021-05-14 at 10:21 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 18:07:04 +0100
> David Woodhouse escreveu:
>
> > On Wed, 2021-05-12 at 14:50 +0200, Mauro Carvalho Chehab wrote:
> > > Such conversion tools - plus some text editor like LibreOffice o
On Tue, 2021-01-05 at 16:40 +0100, Christian König wrote:
> Am 05.01.21 um 13:20 schrieb Huang Rui:
> > On Tue, Jan 05, 2021 at 07:43:51PM +0800, Borislav Petkov wrote:
> > > On Tue, Jan 05, 2021 at 07:08:52PM +0800, Huang Rui wrote:
> > > > Ah, this asic is a bit old and still use radeon driver. S
On Tue, 2020-08-04 at 18:55 +0200, Frank Wunderlich wrote:
> From: Ryder Lee
>
> Add display subsystem related device nodes for MT7623.
>
> Cc: CK Hu
> Signed-off-by: chunhui dai
> Signed-off-by: Bibby Hsieh
> Signed-off-by: Ryder Lee
> Signed-off-by: Frank Wunderlich
> Tested-by: Frank Wun
On Tue, 2020-08-04 at 19:40 +0200, Frank Wunderlich wrote:
> > Gesendet: Dienstag, 04. August 2020 um 19:24 Uhr
> > Von: "David Woodhouse"
> > > + mipi_tx0: mipi-dphy@1001 {
> > > + compatible = "mediatek,mt7623-mipi-tx",
>
On Wed, 2020-08-05 at 09:27 +0200, Frank Wunderlich wrote:
> or should we split dtsi to have a common part (mt7623.dtsi), and one for
> soc (mt7623n.dtsi/mt7623a.dtsi)?
>
> mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts
> mt7623.dtsi => mt7623a.dtsi => mt7623a-unielec-u7623.dts (not ex
On Wed, 2020-08-05 at 10:49 +0200, Frank Wunderlich wrote:
> > Gesendet: Mittwoch, 05. August 2020 um 10:36 Uhr
> > Von: "David Woodhouse"
> > > mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts
> > > mt7623.dtsi => mt7623a.dtsi =&g
From: David Woodhouse
The MT7623A doesn't have a GPU; add it only for MT7623N boards.
Fixes: 1f6ed224594 ("arm: dts: mt7623: add Mali-450 device node")
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/mt7623.dtsi | 24 -
arch/arm/boot/dts/mt762
From: David Woodhouse
Based on a patch in OpenWrt from Kristian Evensen
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/mt7623a-unielec-u7623-emmc.dts | 347 ++
2 files changed, 348 insertions(+)
create mode 100644
From: David Woodhouse
This isn't needed in dtsi files.
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/mt7623a.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index 0735a1fb8ad9..a96075206cce 100644
--- a/arc
On Fri, 2018-02-16 at 10:43 +0100, Norbert Manthey wrote:
> The current implementation will leak a byte to the log via memmove. The
> specified 27 bytes are off-by-one, as the payload is 25 bytes, and the
> termination character is only one byte large. To avoid this, factor out
> the error messag
On Sun, 2013-01-20 at 23:50 +0100, Daniel Vetter wrote:
> DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
> So don't bother, but instead disable it by default to allow distros to
> unconditionally enable DMAR support.
Acked-By: David Woodhouse
It *really* wi
msg33138.html
> Cc: sta...@vger.kernel.org
> Cc: David Woodhouse
> Reported-and-tested-by: Mihai Moldovan
> Signed-off-by: Daniel Vetter
> ---
> drivers/iommu/intel-iommu.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iomm
On Fri, 2012-09-14 at 14:09 +0100, Grant Likely wrote:
> On Fri, Sep 14, 2012 at 2:01 PM, Chris Wilson
> wrote:
> > On Fri, 14 Sep 2012 13:57:06 +0100, Grant Likely
> > wrote:
> >> Some platforms (for instance MacbookPros) have custom backlight drivers
> >> and don't use the integrated i915 bac
On Fri, 2012-09-14 at 14:48 +0100, Matthew Garrett wrote:
> On Fri, Sep 14, 2012 at 01:57:06PM +0100, Grant Likely wrote:
>
> > Tested on MacbookPro8,3. Without this patch both the intel_backlight and
> > gmux_backlight devices get registered and userspace doesn't know which
> > it should use.
>
On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett wrote:
> >
> > > So the user has to choose between 5W of power saving or having dmar? And
> > > we default to giving th
On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> for the dmar+rc6 hangs reported.
Um... let me restate that for clarity (and partly for
On Wed, 2011-11-23 at 16:31 +0100, Daniel Vetter wrote:
>
> Things I've tried that don't work around the issue:
> - Disable dmar for the igfx with intel_iommu=igfx_off
> - Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu
> idling while flushing).
Well, the ILK workaround was only
On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> Hm, that comment confuses me a bit. I've always thought that igfx_off only
> instantiates a identity mapping and leaves the dmar unit on. Is that
> wrong?
It's completely off. If a DMAR unit has *only* graphics devices behind
it (as the on
On Wed, 2011-11-23 at 16:42 -0200, Eugeni Dodonov wrote:
> Those are needed by the rc6 and semaphores support in i915 driver.
>
> In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
> is enabled. So we use those variables to check the io remapping and iommu
> status.
This i
he menu nesting, introduced with
the SmartMedia support. That one is a regression.
I'll concede that I could probably have lived without the DocBook patch,
and the patch to use memdup_user() in mtdchar.c, but they're so trivial
that it seemed pointless rebasing the tree to exclude them o
lear_inode() is the file system's ->clear_inode method, so it
gets called from the VFS when the inode is destroyed, after iput().
I suppose that ought to have been a clue, right from the very beginning,
that we should never have been calling it directly on our e
On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett
> > wrote:
> >
> > > So the user has to choose between 5W of power saving or having dmar? And
> > > we default to givi
On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> for the dmar+rc6 hangs reported.
Um... let me restate that for clarity (and partly for
On Wed, 2011-11-23 at 16:31 +0100, Daniel Vetter wrote:
>
> Things I've tried that don't work around the issue:
> - Disable dmar for the igfx with intel_iommu=igfx_off
> - Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu
> idling while flushing).
Well, the ILK workaround was only
On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> Hm, that comment confuses me a bit. I've always thought that igfx_off only
> instantiates a identity mapping and leaves the dmar unit on. Is that
> wrong?
It's completely off. If a DMAR unit has *only* graphics devices behind
it (as the on
On Wed, 2011-11-23 at 16:42 -0200, Eugeni Dodonov wrote:
> Those are needed by the rc6 and semaphores support in i915 driver.
>
> In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
> is enabled. So we use those variables to check the io remapping and iommu
> status.
This i
he menu nesting, introduced with
the SmartMedia support. That one is a regression.
I'll concede that I could probably have lived without the DocBook patch,
and the patch to use memdup_user() in mtdchar.c, but they're so trivial
that it seemed pointless rebasing the tree to exclude them once I
concluded I should to try my luck at getting the other stuff into -rc2.
--
David WoodhouseOpen Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
lear_inode() is the file system's ->clear_inode method, so it
gets called from the VFS when the inode is destroyed, after iput().
I suppose that ought to have been a clue, right from the very beginning,
that we should never have been calling it directly on our e
On Fri, 2012-09-14 at 14:09 +0100, Grant Likely wrote:
> On Fri, Sep 14, 2012 at 2:01 PM, Chris Wilson
> wrote:
> > On Fri, 14 Sep 2012 13:57:06 +0100, Grant Likely > secretlab.ca> wrote:
> >> Some platforms (for instance MacbookPros) have custom backlight drivers
> >> and don't use the integrat
On Fri, 2012-09-14 at 14:48 +0100, Matthew Garrett wrote:
> On Fri, Sep 14, 2012 at 01:57:06PM +0100, Grant Likely wrote:
>
> > Tested on MacbookPro8,3. Without this patch both the intel_backlight and
> > gmux_backlight devices get registered and userspace doesn't know which
> > it should use.
>
On Sun, 2013-01-20 at 23:50 +0100, Daniel Vetter wrote:
> DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
> So don't bother, but instead disable it by default to allow distros to
> unconditionally enable DMAR support.
Acked-By: David Woodhouse
It *really* wi
.org/msg33138.html
> Cc: stable at vger.kernel.org
> Cc: David Woodhouse
> Reported-and-tested-by: Mihai Moldovan
> Signed-off-by: Daniel Vetter
> ---
> drivers/iommu/intel-iommu.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/driv
On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
> > > > I can't see adding calls li
On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
>
> > Certainly, if it literally is adding of_* calls then that would seem to
> > be gratuitously firmware-specific. Nothing should be using those these
> > days; any new code should be using the generic device property APIs
> > (except in spec
On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > But the point I'm making is that we are working towards *fixing* that,
> > and *not* using DT-specific code in places where we should be using the
> > generic APIs.
>
> What is the plan for fixing things here? It's not obvious (at least to
On Mon, 2015-10-19 at 16:43 +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> > I don't know that there *is* a coherent plan here to address it
> > all.
> >
> > Certainly, we *will* need subsystems to have
41 matches
Mail list logo
