Add as370 to existing berlin pinctrl device tree binding.
Signed-off-by: Jisheng Zhang
---
Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
Add as370 to existing berlin pinctrl device tree binding.
Signed-off-by: Jisheng Zhang
---
Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt
This series is to add the Synaptics AS370 SoC pinctrl driver.
since v1:
- remove MODULE_DEVICE_TABLE since the driver is non-modular. Thank
kbuild test robot to report this issue.
Jisheng Zhang (2):
dt-binding: pinctrl: berlin: document AS370 SoC pinctrl
pinctrl: berlin: add the as370
This series is to add the Synaptics AS370 SoC pinctrl driver.
since v1:
- remove MODULE_DEVICE_TABLE since the driver is non-modular. Thank
kbuild test robot to report this issue.
Jisheng Zhang (2):
dt-binding: pinctrl: berlin: document AS370 SoC pinctrl
pinctrl: berlin: add the as370
On 26-05-18, 19:21, Wei Xu wrote:
> Hi Viresh,
>
> On 2018/5/26 19:00, Wei Xu wrote:
> > Hi Viresh,
> >
> > On 2018/5/25 6:40, Viresh Kumar wrote:
> >> The cooling device properties, like "#cooling-cells" and
> >> "dynamic-power-coefficient", should either be present for all the CPUs
> >> of a
On 26-05-18, 19:21, Wei Xu wrote:
> Hi Viresh,
>
> On 2018/5/26 19:00, Wei Xu wrote:
> > Hi Viresh,
> >
> > On 2018/5/25 6:40, Viresh Kumar wrote:
> >> The cooling device properties, like "#cooling-cells" and
> >> "dynamic-power-coefficient", should either be present for all the CPUs
> >> of a
On 17-07-18, 09:46, Geert Uytterhoeven wrote:
> Hi Viresh,
>
> CC device-tree folks
>
> Replying to an old email, because that's the most accurate reference I
> could find.
>
> On Tue, Feb 9, 2016 at 6:06 AM Viresh Kumar wrote:
> > OPP core can handle the regulators by itself, and but it needs
On 17-07-18, 09:46, Geert Uytterhoeven wrote:
> Hi Viresh,
>
> CC device-tree folks
>
> Replying to an old email, because that's the most accurate reference I
> could find.
>
> On Tue, Feb 9, 2016 at 6:06 AM Viresh Kumar wrote:
> > OPP core can handle the regulators by itself, and but it needs
On 18-07-18, 11:07, Taniya Das wrote:
> +static int qcom_cpu_resources_init(struct platform_device *pdev,
> +struct device_node *np, unsigned int cpu,
> +unsigned long xo_rate)
> +{
> + struct cpufreq_qcom *c;
> + struct
On 18-07-18, 11:07, Taniya Das wrote:
> +static int qcom_cpu_resources_init(struct platform_device *pdev,
> +struct device_node *np, unsigned int cpu,
> +unsigned long xo_rate)
> +{
> + struct cpufreq_qcom *c;
> + struct
2018-07-16 7:58 GMT+09:00 Ingo Molnar :
>
> * Kees Cook wrote:
>
>> The if_changed kbuild function can only be used once per target. If not
>> it will effectively always trigger, flipping back and forth between the
>> two commands getting recorded. Instead, merge the two commands into a
>> single
2018-07-16 7:58 GMT+09:00 Ingo Molnar :
>
> * Kees Cook wrote:
>
>> The if_changed kbuild function can only be used once per target. If not
>> it will effectively always trigger, flipping back and forth between the
>> two commands getting recorded. Instead, merge the two commands into a
>> single
The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements the cpufreq
driver interface for this hardware engine.
Signed-off-by: Saravana Kannan
Signed-off-by: Taniya Das
---
drivers/cpufreq/Kconfig.arm | 11 ++
The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements the cpufreq
driver interface for this hardware engine.
Signed-off-by: Saravana Kannan
Signed-off-by: Taniya Das
---
drivers/cpufreq/Kconfig.arm | 11 ++
[v6]
* Renamed match table 'qcom_cpufreq_hw_match'.
* Renamed 'qcom_read_lut' to 'qcom_cpufreq_hw_read_lut'.
* Updated the logic to check for related CPUs at the beginning of the
'qcom_cpu_resources_init'.
* Use devm_ioremap_resource instead of devm_ioremap.
* Update the use of of_node_put
Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
SoCs. This is required for managing the cpu frequency transitions which are
controlled by the hardware engine.
Signed-off-by: Taniya Das
---
.../bindings/cpufreq/cpufreq-qcom-hw.txt | 172 +
1
[v6]
* Renamed match table 'qcom_cpufreq_hw_match'.
* Renamed 'qcom_read_lut' to 'qcom_cpufreq_hw_read_lut'.
* Updated the logic to check for related CPUs at the beginning of the
'qcom_cpu_resources_init'.
* Use devm_ioremap_resource instead of devm_ioremap.
* Update the use of of_node_put
Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
SoCs. This is required for managing the cpu frequency transitions which are
controlled by the hardware engine.
Signed-off-by: Taniya Das
---
.../bindings/cpufreq/cpufreq-qcom-hw.txt | 172 +
1
Hello Stephen,
Thanks for the review comments.
On 7/13/2018 5:14 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-07-12 11:05:45)
The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements the cpufreq
driver interface
Hello Stephen,
Thanks for the review comments.
On 7/13/2018 5:14 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-07-12 11:05:45)
The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements the cpufreq
driver interface
On 17-07-18, 11:40, Rob Herring wrote:
> On Tue, Jul 17, 2018 at 9:34 AM Vinod wrote:
> >
> > On 16-07-18, 15:33, Rob Herring wrote:
> > > On Mon, Jul 09, 2018 at 10:42:26PM +0530, Vinod wrote:
> > > > On 03-07-18, 14:32, Paul Cercueil wrote:
> > > >
> > > > > enum jz_version {
> > > > > +
On 17-07-18, 11:40, Rob Herring wrote:
> On Tue, Jul 17, 2018 at 9:34 AM Vinod wrote:
> >
> > On 16-07-18, 15:33, Rob Herring wrote:
> > > On Mon, Jul 09, 2018 at 10:42:26PM +0530, Vinod wrote:
> > > > On 03-07-18, 14:32, Paul Cercueil wrote:
> > > >
> > > > > enum jz_version {
> > > > > +
On Tuesday 17 July 2018 01:33 PM, Tony Lindgren wrote:
> * Stephen Rothwell [180717 08:03]:
>> Hi Tony,
>>
>> On Mon, 16 Jul 2018 23:08:08 -0700 Tony Lindgren wrote:
>>>
>>> The following regression is still pending in next, see below.
>>>
>>> * Samuel Morris [180702 13:35]:
On Mon, Jul
On Tuesday 17 July 2018 01:33 PM, Tony Lindgren wrote:
> * Stephen Rothwell [180717 08:03]:
>> Hi Tony,
>>
>> On Mon, 16 Jul 2018 23:08:08 -0700 Tony Lindgren wrote:
>>>
>>> The following regression is still pending in next, see below.
>>>
>>> * Samuel Morris [180702 13:35]:
On Mon, Jul
On 17-07-18, 22:48, Niklas Cassel wrote:
> If of_nvmem_cell_get() fails due to probe deferal, we shouldn't print an
> error message. Just be silent in this case.
>
> Signed-off-by: Niklas Cassel
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 5 +++--
> 1 file changed, 3 insertions(+), 2
On 17-07-18, 22:48, Niklas Cassel wrote:
> If of_nvmem_cell_get() fails due to probe deferal, we shouldn't print an
> error message. Just be silent in this case.
>
> Signed-off-by: Niklas Cassel
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 5 +++--
> 1 file changed, 3 insertions(+), 2
Hello,
syzbot found the following crash on:
HEAD commit:dc989d2ce2c2 tools: bpftool: don't pass FEATURES_DUMP to l..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10a9a97840
kernel config: https://syzkaller.appspot.com/x/.config?x=89129667b46496c3
Hello,
syzbot found the following crash on:
HEAD commit:dc989d2ce2c2 tools: bpftool: don't pass FEATURES_DUMP to l..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1428957840
kernel config: https://syzkaller.appspot.com/x/.config?x=89129667b46496c3
Hello,
syzbot found the following crash on:
HEAD commit:dc989d2ce2c2 tools: bpftool: don't pass FEATURES_DUMP to l..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10a9a97840
kernel config: https://syzkaller.appspot.com/x/.config?x=89129667b46496c3
Hello,
syzbot found the following crash on:
HEAD commit:dc989d2ce2c2 tools: bpftool: don't pass FEATURES_DUMP to l..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1428957840
kernel config: https://syzkaller.appspot.com/x/.config?x=89129667b46496c3
On Tue, 17 Jul 2018, Arnd Bergmann wrote:
> The firmware_loader can be built as a loadable module, which now
> fails when CONFIG_SECURITY is enabled, because a call to the
> security_kernel_load_data() function got added, and this is
> not exported to modules:
>
> ERROR:
On Tue, 17 Jul 2018, Arnd Bergmann wrote:
> The firmware_loader can be built as a loadable module, which now
> fails when CONFIG_SECURITY is enabled, because a call to the
> security_kernel_load_data() function got added, and this is
> not exported to modules:
>
> ERROR:
Hi Matthias
On Tue, 2018-07-17 at 12:24 +0200, Matthias Brugger wrote:
>
> On 17/07/18 10:52, Mars Cheng wrote:
> > Signed-off-by: Mars Cheng
> > Signed-off-by: Owen Chen
>
> Please provide a commit message.
>
> Thanks,
> Matthias
Got it, it is my bad, will add it.
Thanks.
>
> > ---
> >
Hi Matthias
On Tue, 2018-07-17 at 12:24 +0200, Matthias Brugger wrote:
>
> On 17/07/18 10:52, Mars Cheng wrote:
> > Signed-off-by: Mars Cheng
> > Signed-off-by: Owen Chen
>
> Please provide a commit message.
>
> Thanks,
> Matthias
Got it, it is my bad, will add it.
Thanks.
>
> > ---
> >
On Tue, Jul 17, 2018 at 10:21:38AM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trival fix to two spellling mistakes
Thank you very much for this fixing. Only one minor thing here.
s/Trival/Trivial/
s/spellling/spelling/
Thanks
Hao
> "execeeded" -> "exceeded"
> "Invaild" -> "Invalid"
(cc linux-mm)
On Tue, 3 Jul 2018 08:43:23 +0200 Bruce Merry wrote:
> Hi
>
> I've run into an odd performance issue in the kernel, and not being a
> kernel dev or knowing terribly much about cgroups, am looking for
> advice on diagnosing the problem further (I discovered this while
> trying to
On Tue, Jul 17, 2018 at 10:21:38AM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trival fix to two spellling mistakes
Thank you very much for this fixing. Only one minor thing here.
s/Trival/Trivial/
s/spellling/spelling/
Thanks
Hao
> "execeeded" -> "exceeded"
> "Invaild" -> "Invalid"
(cc linux-mm)
On Tue, 3 Jul 2018 08:43:23 +0200 Bruce Merry wrote:
> Hi
>
> I've run into an odd performance issue in the kernel, and not being a
> kernel dev or knowing terribly much about cgroups, am looking for
> advice on diagnosing the problem further (I discovered this while
> trying to
Hello Davidlohr,
On 07/17/2018 07:26 AM, Davidlohr Bueso wrote:
In order for load/store tearing to work, _all_ accesses to
the variable in question need to be done around READ and
WRITE_ONCE() macros. Ensure everyone does so for q->status
variable for semtimedop().
What is the background of
Hello Davidlohr,
On 07/17/2018 07:26 AM, Davidlohr Bueso wrote:
In order for load/store tearing to work, _all_ accesses to
the variable in question need to be done around READ and
WRITE_ONCE() macros. Ensure everyone does so for q->status
variable for semtimedop().
What is the background of
On Thu, 21 Jun 2018 17:07:08 -0400 William Breathitt Gray
wrote:
> This patch introduces the Generic Counter interface for supporting
> counter devices.
>
+EXPORT_SYMBOL(count_direction_str);
+EXPORT_SYMBOL(count_mode_str);
+EXPORT_SYMBOL(counter_signal_enum_read);
On Thu, 21 Jun 2018 17:07:08 -0400 William Breathitt Gray
wrote:
> This patch introduces the Generic Counter interface for supporting
> counter devices.
>
+EXPORT_SYMBOL(count_direction_str);
+EXPORT_SYMBOL(count_mode_str);
+EXPORT_SYMBOL(counter_signal_enum_read);
piaojun wrote on Wed, Jul 18, 2018:
> Fix spelling mistake in comments of p9_virtio_zc_request().
>
> Signed-off-by: Jun Piao
Thanks, queued it.
> ---
> net/9p/trans_virtio.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/9p/trans_virtio.c
piaojun wrote on Wed, Jul 18, 2018:
> Fix spelling mistake in comments of p9_virtio_zc_request().
>
> Signed-off-by: Jun Piao
Thanks, queued it.
> ---
> net/9p/trans_virtio.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/9p/trans_virtio.c
Fix spelling mistake in comments of p9_virtio_zc_request().
Signed-off-by: Jun Piao
---
net/9p/trans_virtio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index c9f2717..86077f7 100644
--- a/net/9p/trans_virtio.c
+++
Fix spelling mistake in comments of p9_virtio_zc_request().
Signed-off-by: Jun Piao
---
net/9p/trans_virtio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index c9f2717..86077f7 100644
--- a/net/9p/trans_virtio.c
+++
On Wed, Jul 18, 2018 at 4:59 AM Matthias Kaehlcke wrote:
>
> On Thu, Jul 12, 2018 at 02:09:03PM +0530, Amit Kucheria wrote:
> > There are two banks of registers for v2 TSENS IPs: SROT and TM. On older
> > SoCs these were contiguous, leading to DTs mapping them as one register
> > address space of
On Wed, Jul 18, 2018 at 4:59 AM Matthias Kaehlcke wrote:
>
> On Thu, Jul 12, 2018 at 02:09:03PM +0530, Amit Kucheria wrote:
> > There are two banks of registers for v2 TSENS IPs: SROT and TM. On older
> > SoCs these were contiguous, leading to DTs mapping them as one register
> > address space of
On Tue, Jul 17, 2018 at 08:27:53PM -0700, Andrew Morton wrote:
> On Tue, 17 Jul 2018 20:24:05 -0700 Omar Sandoval wrote:
>
> > > > --- a/fs/proc/kcore.c
> > > > +++ b/fs/proc/kcore.c
> > > > @@ -59,8 +59,8 @@ struct memelfnote
> > > > };
> > > >
> > > > static LIST_HEAD(kclist_head);
> > > >
On Tue, Jul 17, 2018 at 08:27:53PM -0700, Andrew Morton wrote:
> On Tue, 17 Jul 2018 20:24:05 -0700 Omar Sandoval wrote:
>
> > > > --- a/fs/proc/kcore.c
> > > > +++ b/fs/proc/kcore.c
> > > > @@ -59,8 +59,8 @@ struct memelfnote
> > > > };
> > > >
> > > > static LIST_HEAD(kclist_head);
> > > >
Hi Al,
On Wed, 18 Jul 2018 03:56:37 +0100 Al Viro wrote:
>
> ... and now it even builds. Said that, I would really like to hear something
> from you - I can duplicate the entire overlayfs-next and merge it into
> my #for-next and ask Steven to use that instead of your tree, but I very
> much
Hi Al,
On Wed, 18 Jul 2018 03:56:37 +0100 Al Viro wrote:
>
> ... and now it even builds. Said that, I would really like to hear something
> from you - I can duplicate the entire overlayfs-next and merge it into
> my #for-next and ask Steven to use that instead of your tree, but I very
> much
On Tue, Jul 17, 2018 at 07:44:21PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2018 17:09:39 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > The vmcoreinfo information is useful for runtime debugging tools, not
> > just for crash dumps. A lot of this information can be determined
The kernel documentation is now restructured text. Convert the Ethernet
Bridge documentation and include it in the toplevel kernel
documentation.
- Fix heading adornments.
- Add license identifier.
Signed-off-by: Tobin C. Harding
---
Documentation/networking/{bridge.txt => bridge.rst} | 6
The kernel documentation is now restructured text. Convert the IP
aliasing documentation and include it in the toplevel kernel
documentation.
- Fix heading adornments.
- Correctly indent code snippets.
- Limit line length to 72 characters inline with kernel documentation
standards.
- Add
On Tue, Jul 17, 2018 at 07:44:21PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2018 17:09:39 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > The vmcoreinfo information is useful for runtime debugging tools, not
> > just for crash dumps. A lot of this information can be determined
The kernel documentation is now restructured text. Convert the Ethernet
Bridge documentation and include it in the toplevel kernel
documentation.
- Fix heading adornments.
- Add license identifier.
Signed-off-by: Tobin C. Harding
---
Documentation/networking/{bridge.txt => bridge.rst} | 6
The kernel documentation is now restructured text. Convert the IP
aliasing documentation and include it in the toplevel kernel
documentation.
- Fix heading adornments.
- Correctly indent code snippets.
- Limit line length to 72 characters inline with kernel documentation
standards.
- Add
On Tue, 17 Jul 2018 20:24:05 -0700 Omar Sandoval wrote:
> > > --- a/fs/proc/kcore.c
> > > +++ b/fs/proc/kcore.c
> > > @@ -59,8 +59,8 @@ struct memelfnote
> > > };
> > >
> > > static LIST_HEAD(kclist_head);
> > > -static DEFINE_RWLOCK(kclist_lock);
> > > -static int kcore_need_update = 1;
> >
On Tue, 17 Jul 2018 20:24:05 -0700 Omar Sandoval wrote:
> > > --- a/fs/proc/kcore.c
> > > +++ b/fs/proc/kcore.c
> > > @@ -59,8 +59,8 @@ struct memelfnote
> > > };
> > >
> > > static LIST_HEAD(kclist_head);
> > > -static DEFINE_RWLOCK(kclist_lock);
> > > -static int kcore_need_update = 1;
> >
Dave Hansen writes:
>> @@ -878,6 +877,11 @@ static int swap_alloc_cluster(struct swap_info_struct
>> *si, swp_entry_t *slot)
>> unsigned long offset, i;
>> unsigned char *map;
>>
>> +if (!IS_ENABLED(CONFIG_THP_SWAP)) {
>> +VM_WARN_ON_ONCE(1);
>> +return
Dave Hansen writes:
>> @@ -878,6 +877,11 @@ static int swap_alloc_cluster(struct swap_info_struct
>> *si, swp_entry_t *slot)
>> unsigned long offset, i;
>> unsigned char *map;
>>
>> +if (!IS_ENABLED(CONFIG_THP_SWAP)) {
>> +VM_WARN_ON_ONCE(1);
>> +return
On Tue, Jul 17, 2018 at 07:38:41PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2018 17:09:34 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > Now we only need kclist_lock from user context and at fs init time, and
> > the following changes need to sleep while holding the
On Tue, Jul 17, 2018 at 07:38:41PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2018 17:09:34 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > Now we only need kclist_lock from user context and at fs init time, and
> > the following changes need to sleep while holding the
On Tue, Jul 17, 2018 at 07:35:04PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2018 17:09:33 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > kclist_add() is only called at init time, so there's no point in
> > grabbing any locks. We're also going to replace the rwlock with a
On Tue, Jul 17, 2018 at 07:35:04PM -0700, Andrew Morton wrote:
> On Thu, 12 Jul 2018 17:09:33 -0700 Omar Sandoval wrote:
>
> > From: Omar Sandoval
> >
> > kclist_add() is only called at init time, so there's no point in
> > grabbing any locks. We're also going to replace the rwlock with a
On Wed, 18 Jul 2018, Adam Borowski wrote:
> Hi!
> Based on Nicolas' nice work (in tty-next), let's avoid corrupting characters
> that have been copy+pasted via mouse selection. The uniscr array holds
> their original identity even if they got mangled by glyph conversion.
> The glyph conversion
On Wed, 18 Jul 2018, Adam Borowski wrote:
> Hi!
> Based on Nicolas' nice work (in tty-next), let's avoid corrupting characters
> that have been copy+pasted via mouse selection. The uniscr array holds
> their original identity even if they got mangled by glyph conversion.
> The glyph conversion
Dave Hansen writes:
> On 07/16/2018 05:55 PM, Huang, Ying wrote:
>> +/*
>> + * For non-HDD swap devices, the fine grained cluster lock is used to
>> + * protect si->swap_map. But cluster and cluster locks isn't
>> + * available for HDD, so coarse grained si->lock will be used instead
>> + * for
Dave Hansen writes:
> On 07/16/2018 05:55 PM, Huang, Ying wrote:
>> +/*
>> + * For non-HDD swap devices, the fine grained cluster lock is used to
>> + * protect si->swap_map. But cluster and cluster locks isn't
>> + * available for HDD, so coarse grained si->lock will be used instead
>> + * for
Let's keep \e[5m setting this bit, it's a nice way to convey the
information, and it preserves old behaviour. Some other terminals
that can't or don't want to blink do so as well.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Let's keep \e[5m setting this bit, it's a nice way to convey the
information, and it preserves old behaviour. Some other terminals
that can't or don't want to blink do so as well.
Signed-off-by: Adam Borowski
---
drivers/tty/vt/vt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Hasn't been ever used within historic (ie, git) times.
Signed-off-by: Adam Borowski
---
include/linux/console_struct.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 2c8d3239899b..fea64f2692a0 100644
Marks consoles that interpret the blink bit by showing bright background
instead. Doesn't matter if the console can't do either.
For now, turn it on for fbcon when in color mode. Vgacon can also do so
but requires setting appropriate VGA register (bit 3 of AMCR). I don't
know other consoles:
The algorithm for 256-to-16 conversion was designed with wrong input
palette but actually tuned on mainstream GUI terminals. This resulted in
something that works well only for data we convert ourselves (ie, 256 not
24-bit).
As the change is non-linear, I did not bother replicating it exactly,
Turns out that osso-xterm which I based upon uses something a lot different
from apparently any other terminal -- they all use identical shades, much
brighter than what I copied:
Old: 00 2a 55 7f aa d4
New: 00 5f 87 af d7 ff
This did hardly matter as we immediately shoehorn the colors
This improves schemes used by fancy new programs. For example, it lets
bright powerline segments match, and fixes images shown by catimg being
striped to the point of unreadability.
Handling of 8-color backgrounds uses stripped 16-color value instead of a
dedicated formula; this works worse for
Hasn't been ever used within historic (ie, git) times.
Signed-off-by: Adam Borowski
---
include/linux/console_struct.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index 2c8d3239899b..fea64f2692a0 100644
Marks consoles that interpret the blink bit by showing bright background
instead. Doesn't matter if the console can't do either.
For now, turn it on for fbcon when in color mode. Vgacon can also do so
but requires setting appropriate VGA register (bit 3 of AMCR). I don't
know other consoles:
The algorithm for 256-to-16 conversion was designed with wrong input
palette but actually tuned on mainstream GUI terminals. This resulted in
something that works well only for data we convert ourselves (ie, 256 not
24-bit).
As the change is non-linear, I did not bother replicating it exactly,
Turns out that osso-xterm which I based upon uses something a lot different
from apparently any other terminal -- they all use identical shades, much
brighter than what I copied:
Old: 00 2a 55 7f aa d4
New: 00 5f 87 af d7 ff
This did hardly matter as we immediately shoehorn the colors
This improves schemes used by fancy new programs. For example, it lets
bright powerline segments match, and fixes images shown by catimg being
striped to the point of unreadability.
Handling of 8-color backgrounds uses stripped 16-color value instead of a
dedicated formula; this works worse for
Hi!
Here's a patchset with two entangled improvements:
* it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
allows disabling it, rendering such characters with a bright background
instead.
* due to my error, 256-color mode uses a much darker palette for conversion,
Hi!
Here's a patchset with two entangled improvements:
* it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
allows disabling it, rendering such characters with a bright background
instead.
* due to my error, 256-color mode uses a much darker palette for conversion,
Gentle ping, hope this series can catch up with the next merge window. :)
On Tue, 3 Jul 2018 at 14:21, Wanpeng Li wrote:
>
> Using hypercall to send IPIs by one vmexit instead of one by one for
> xAPIC/x2APIC physical mode and one vmexit per-cluster for x2APIC cluster
> mode. Intel guest can
Gentle ping, hope this series can catch up with the next merge window. :)
On Tue, 3 Jul 2018 at 14:21, Wanpeng Li wrote:
>
> Using hypercall to send IPIs by one vmexit instead of one by one for
> xAPIC/x2APIC physical mode and one vmexit per-cluster for x2APIC cluster
> mode. Intel guest can
Daniel Jordan writes:
> On Tue, Jul 17, 2018 at 08:55:49AM +0800, Huang, Ying wrote:
>> This patchset is based on 2018-07-13 head of mmotm tree.
>
> Looks good.
>
> Still think patch 7 would be easier to review if split into two logical
> changes. Either way, though.
>
> For the series,
>
Daniel Jordan writes:
> On Tue, Jul 17, 2018 at 08:55:49AM +0800, Huang, Ying wrote:
>> This patchset is based on 2018-07-13 head of mmotm tree.
>
> Looks good.
>
> Still think patch 7 would be easier to review if split into two logical
> changes. Either way, though.
>
> For the series,
>
Dave Hansen writes:
> On 07/16/2018 05:55 PM, Huang, Ying wrote:
>> text data bss dec hex filename
>> base: 24215 2028 340 2658367d7 mm/swapfile.o
>> unified: 245772028 340 269456941 mm/swapfile.o
>
> That's a bit
On Thu, Jul 12, 2018 at 04:53:37PM +0100, Al Viro wrote:
> On Thu, Jul 12, 2018 at 08:05:26AM -0700, Linus Torvalds wrote:
> > On Thu, Jul 12, 2018 at 5:43 AM Al Viro wrote:
> > >
> > > A question regarding the customs in such situations - are previous
> > > Reviewed-by/Acked-by normally kept
Dave Hansen writes:
> On 07/16/2018 05:55 PM, Huang, Ying wrote:
>> text data bss dec hex filename
>> base: 24215 2028 340 2658367d7 mm/swapfile.o
>> unified: 245772028 340 269456941 mm/swapfile.o
>
> That's a bit
On Thu, Jul 12, 2018 at 04:53:37PM +0100, Al Viro wrote:
> On Thu, Jul 12, 2018 at 08:05:26AM -0700, Linus Torvalds wrote:
> > On Thu, Jul 12, 2018 at 5:43 AM Al Viro wrote:
> > >
> > > A question regarding the customs in such situations - are previous
> > > Reviewed-by/Acked-by normally kept
On Wed, 18 Jul 2018, Adam Borowski wrote:
> On Tue, Jul 17, 2018 at 09:02:40PM -0400, Nicolas Pitre wrote:
> > The nr argument is typically small: most often nr == 1. However this
> > could be abused with a very large explicit scroll in a resized screen.
> > Make the code scroll lines one at a
On Wed, 18 Jul 2018, Adam Borowski wrote:
> On Tue, Jul 17, 2018 at 09:02:40PM -0400, Nicolas Pitre wrote:
> > The nr argument is typically small: most often nr == 1. However this
> > could be abused with a very large explicit scroll in a resized screen.
> > Make the code scroll lines one at a
On Thu, 12 Jul 2018 17:09:39 -0700 Omar Sandoval wrote:
> From: Omar Sandoval
>
> The vmcoreinfo information is useful for runtime debugging tools, not
> just for crash dumps. A lot of this information can be determined by
> other means, but this is much more convenient.
>
What effect does
On Thu, 12 Jul 2018 17:09:39 -0700 Omar Sandoval wrote:
> From: Omar Sandoval
>
> The vmcoreinfo information is useful for runtime debugging tools, not
> just for crash dumps. A lot of this information can be determined by
> other means, but this is much more convenient.
>
What effect does
On Wed, Jul 4, 2018 at 2:54 AM, Louis Collard wrote:
> On Fri, Jun 29, 2018 at 9:03 PM, David R. Bild wrote:
>> As a point of clarification (and correct me if I'm wrong), the TPM is
>> always ready used to seed the rng. It just doesn't update the entropy
>> pool estimate.
>
> Good point.
>
>>
>>
On Wed, Jul 4, 2018 at 2:54 AM, Louis Collard wrote:
> On Fri, Jun 29, 2018 at 9:03 PM, David R. Bild wrote:
>> As a point of clarification (and correct me if I'm wrong), the TPM is
>> always ready used to seed the rng. It just doesn't update the entropy
>> pool estimate.
>
> Good point.
>
>>
>>
On Thu, 12 Jul 2018 17:09:34 -0700 Omar Sandoval wrote:
> From: Omar Sandoval
>
> Now we only need kclist_lock from user context and at fs init time, and
> the following changes need to sleep while holding the kclist_lock.
>
> ...
>
> --- a/fs/proc/kcore.c
> +++ b/fs/proc/kcore.c
> @@ -59,8
On Thu, 12 Jul 2018 17:09:34 -0700 Omar Sandoval wrote:
> From: Omar Sandoval
>
> Now we only need kclist_lock from user context and at fs init time, and
> the following changes need to sleep while holding the kclist_lock.
>
> ...
>
> --- a/fs/proc/kcore.c
> +++ b/fs/proc/kcore.c
> @@ -59,8
1 - 100 of 1900 matches
Mail list logo
