nce only the parts requiring I/O ports and print an
> error message if a device can't be supported with the current
> configuration.
>
> Co-developed-by: Arnd Bergmann
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Niklas Schnelle
> ---
Reviewed-by: Maciej W. Rozycki
Maciej
On Tue, 8 Oct 2024, Niklas Schnelle wrote:
> > > +static __always_inline bool is_upf_fourport(struct uart_port *port)
> > > +{
> > > + if (!IS_ENABLED(CONFIG_HAS_IOPORT))
> > > + return false;
> > > +
> > > + return port->flags & UPF_FOURPORT;
> > > +}
> >
> > Can we perhaps avoid adding
On Mon, 7 Oct 2024, Niklas Schnelle wrote:
> diff --git a/drivers/tty/serial/8250/8250_pci.c
> b/drivers/tty/serial/8250/8250_pci.c
> index
> 6709b6a5f3011db38acc58dc7223158fe4fcf72e..6a638feb44e443a1998980dd037748f227ec1bc8
> 100644
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tt
On Fri, 6 Oct 2023, Sui Jingfeng wrote:
> > I think this makes sense per the spec, but there's always a risk of
> > breaking something, so it's nice if the change actually *fixes*
> > something to make that risk worthwhile.
>
>
> Maciej mentioned that PCI_CLASS_NOT_DEFINED_VGA device should also
On Tue, 13 Jun 2023, Sui Jingfeng wrote:
> Deal only with the VGA devcie(pdev->class == 0x0300), so replace the
Typo here: s/devcie/device/.
> pci_get_subsys() function with pci_get_class(). Filter the non-PCI display
> device(pdev->class != 0x0300) out. There no need to process the non-display
Hi Geert,
> > > .> [1]
> > > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/9abf2313adc1ca1b6180c508c25f22f9395cc780/
> > > (all 149 configs)
>
> > > > + {standard input}: Error: branch to a symbol in another ISA mode:
> > > > 1339 =>
> > > > 2616, 2621
> > >
> > > mips-gcc11/micro32r2
On Mon, 17 Oct 2022, Geert Uytterhoeven wrote:
> > + {standard input}: Error: branch to a symbol in another ISA mode: 1339 =>
> > 2616, 2621
>
> mips-gcc11/micro32r2_defconfig
> mips-gcc11/micro32r2el_defconfig
Where can these configs be obtained from?
Maciej
e' rather than
afterwards, so that first the call has a chance to use them and second
they do not change the console structure to something possibly different
from what was used by `vc_resize'.
Move the propagation of the vgacon boot parameters ahead of the call to
`vc_resize' the
On Sat, 15 May 2021, Maciej W. Rozycki wrote:
> On Sat, 15 May 2021, Tetsuo Handa wrote:
>
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index 3406067985b1..22bb3892f6bd 100644
> > --- a/drivers/video/fbdev/core/f
eek or so as I'm currently away from my lab and this
requires physical presence.
Reviewed-by: Maciej W. Rozycki
Maciej
On Fri, 14 May 2021, Linus Torvalds wrote:
> > Overall I think it does make sense to resize the text console at any
> > time, even if the visible console (VT) chosen is in the graphics mode,
>
> It might make sense, but only if we call the function to update the
> low-level data.
>
> Not callin
On Fri, 14 May 2021, Linus Torvalds wrote:
> > Currently it is impossible to control upper limit of rows/columns values
> > based on amount of memory reserved for the graphical screen, for
> > resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not
> > already KD_GRAPHICS
>
> Hon
lank. The proportions change according to text mode geometries chosen.
Revert the change verbatim then, bringing back previous VT resizing.
Signed-off-by: Maciej W. Rozycki
Fixes: 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE")
Cc: sta...@vger.kernel.org # v5.10+
--
uity.
References:
[1]
https://syzkaller.appspot.com/bug?id=32577e96d88447ded2d3b76d71254fb855245837
[2]
https://syzkaller.appspot.com/bug?id=6b8355d27b2b94fb5cedf4655e3a59162d9e48e3
Signed-off-by: Maciej W. Rozycki
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kern
rt of the screen. Of course the
proportions change according to text mode geometries and font sizes
chosen.
Address the problem then, by updating the text mode geometry defaults
rather than checking against them whenever the VT is resized via a user
ioctl.
Signed-off-by: Maciej W. Rozycki
Hi,
This is a minor update to the previous version of the series, adding a
clarification to 3/3 as to the problem the original fix to which caused
the functional regression the removal of extra VT_RESIZEX parameter
handling caused. No change to actual code.
See individual change description
if (clin)
- video_font_height = clin;
+ vc->vc_font.height = clin;
making the parameter apply to framebuffer devices as well, perhaps due
to the use of "font" in the name of the original `video_font_height'
variable. Us
lank. The proportions change according to text mode geometries chosen.
Revert the change verbatim then, bringing back previous VT resizing.
Signed-off-by: Maciej W. Rozycki
Fixes: 988d0763361b ("vt_ioctl: make VT_RESIZEX behave like VT_RESIZE")
Cc: sta...@vger.kernel.org # v5.10+
---
drive
Hi,
I got to the bottom of the issue with VT_RESIZEX recently discussed and
came up with this small patch series, fixing an additional issue that I
originally thought might be broken VGA hardware emulation with my laptop,
which however turned out to be intertwined with the original problem and
rt of the screen. Of course the
proportions change according to text mode geometries and font sizes
chosen.
Address the problem then, by updating the text mode geometry defaults
rather than checking against them whenever the VT is resized via a user
ioctl.
Signed-off-by: Maciej W. Rozycki
On Mon, 12 Apr 2021, Daniel Vetter wrote:
> > Note that it's entirely possible that things continue to work well
> > despite this warning. It's unclear to me from your email if you
> > actually see any difference (and apparently you're not able to see it
> > right now due to not being close to the
On Tue, 29 Sep 2020, Greg KH wrote:
> > > > >> VT_RESIZEX was introduced in Linux 1.3.3, but it is unclear that what
> > > > >> comes to the "+ more" part, and I couldn't find a user of VT_RESIZEX.
> > > > >>
> > > > >
> > > > > It seems this is/was used by "svgatextmode" which seems to be at
> >
22 matches
Mail list logo
