> +/*
> + * Nag about hardware bugs, hopefully to have vendors fix them, but at least
> + * to collect a list of dependencies for the VF INTx pin quirk below.
> + */
> +static const struct pci_device_id known_bogus_vf_intx_pin[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x270c) },
> + {}
>
> +/*
> + * Nag about hardware bugs, hopefully to have vendors fix them, but at least
> + * to collect a list of dependencies for the VF INTx pin quirk below.
> + */
> +static const struct pci_device_id known_bogus_vf_intx_pin[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x270c) },
> + {}
>
On 9/20/2018 7:19 PM, Matthias Kaehlcke wrote:
If the existing users populate a custom property with the BD address
in the bootloader you could roll out a bootloader change. You'd have
to make sure that bootloader and kernel match. The bootloader could
still populate the custom property to be
On 9/20/2018 7:19 PM, Matthias Kaehlcke wrote:
If the existing users populate a custom property with the BD address
in the bootloader you could roll out a bootloader change. You'd have
to make sure that bootloader and kernel match. The bootloader could
still populate the custom property to be
On Thu, Sep 20, 2018 at 10:52 AM Palmer Dabbelt wrote:
>
> On Fri, 14 Sep 2018 07:37:20 PDT (-0700), ren_...@c-sky.com wrote:
> > On Wed, Sep 12, 2018 at 04:30:36PM +0200, Arnd Bergmann wrote:
> >> On Wed, Sep 12, 2018 at 3:25 PM Guo Ren wrote:
> I don't want to hijack this thread, but in RISC-V
On Thu, Sep 20, 2018 at 10:52 AM Palmer Dabbelt wrote:
>
> On Fri, 14 Sep 2018 07:37:20 PDT (-0700), ren_...@c-sky.com wrote:
> > On Wed, Sep 12, 2018 at 04:30:36PM +0200, Arnd Bergmann wrote:
> >> On Wed, Sep 12, 2018 at 3:25 PM Guo Ren wrote:
> I don't want to hijack this thread, but in RISC-V
On 21/09/2018 04:08, peng.h...@zte.com.cn wrote:
>>> Unqueued, sorry. The hypercall test from kvm-unit-tests fails. A
>>> VMCALL on the "edge" of canonical address space, i.e. at 0x7ffd,
>>> raises a general protection fault before this patch and a double fault
>>> afterwards.
>> Peng
On 21/09/2018 04:08, peng.h...@zte.com.cn wrote:
>>> Unqueued, sorry. The hypercall test from kvm-unit-tests fails. A
>>> VMCALL on the "edge" of canonical address space, i.e. at 0x7ffd,
>>> raises a general protection fault before this patch and a double fault
>>> afterwards.
>> Peng
G'day Song,
One more comment below.
On 20/09/2018 9:46 PM, Peter Meerwald-Stadler wrote:
On Thu, 20 Sep 2018, Song Qiang wrote:
PNI RM3100 magnetometer is a high resolution, large signal immunity
magnetometer, composed of 3 single sensors and a processing chip.
PNI is currently not in the
G'day Song,
One more comment below.
On 20/09/2018 9:46 PM, Peter Meerwald-Stadler wrote:
On Thu, 20 Sep 2018, Song Qiang wrote:
PNI RM3100 magnetometer is a high resolution, large signal immunity
magnetometer, composed of 3 single sensors and a processing chip.
PNI is currently not in the
On Thu, Sep 20, 2018 at 6:46 PM, zhong jiang wrote:
> debugfs_remove_recursive has taken the null pointer into account.
> just remove the null check before debugfs_remove_recursive.
>
> Acked-by: Masami Hiramatsu
> Signed-off-by: zhong jiang
Acked-by: Kees Cook
-Kees
> ---
>
On Thu, Sep 20, 2018 at 6:46 PM, zhong jiang wrote:
> debugfs_remove_recursive has taken the null pointer into account.
> just remove the null check before debugfs_remove_recursive.
>
> Acked-by: Masami Hiramatsu
> Signed-off-by: zhong jiang
Acked-by: Kees Cook
-Kees
> ---
>
PERHATIAN;
Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali
memvalidasi email mailbox Anda. Untuk memvalidasi ulang
PERHATIAN;
Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali
memvalidasi email mailbox Anda. Untuk memvalidasi ulang
From: Can Guo
Update the compatible string for UFS QMP PHY on SDM845.
Signed-off-by: Can Guo
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Can Guo
Update the compatible string for UFS QMP PHY on SDM845.
Signed-off-by: Can Guo
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Can Guo
Add core reset support string for UFS.
Signed-off-by: Amit Nischal
Signed-off-by: Can Guo
---
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
From: Can Guo
Add core reset support string for UFS.
Signed-off-by: Amit Nischal
Signed-off-by: Can Guo
---
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
From: Can Guo
Add UFS PHY support to make SDM845 UFS work with common PHY framework.
Signed-off-by: Can Guo
Reviewed-by: Evan Green
Reviewed-by: Vivek Gautam
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 172 +++-
drivers/phy/qualcomm/phy-qcom-qmp.h | 15
2
From: Can Guo
Add UFS PHY support to make SDM845 UFS work with common PHY framework.
Signed-off-by: Can Guo
Reviewed-by: Evan Green
Reviewed-by: Vivek Gautam
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 172 +++-
drivers/phy/qualcomm/phy-qcom-qmp.h | 15
2
From: Can Guo
All PHYs should be powered on before register configuration starts. And
only PCIe PHYs need an extra power control before deasserts reset state.
Signed-off-by: Can Guo
Reviewed-by: Manu Gautam
Reviewed-by: Vivek Gautam
Reviewed-by: Evan Green
---
From: Can Guo
All PHYs should be powered on before register configuration starts. And
only PCIe PHYs need an extra power control before deasserts reset state.
Signed-off-by: Can Guo
Reviewed-by: Manu Gautam
Reviewed-by: Vivek Gautam
Reviewed-by: Evan Green
---
From: Can Guo
Move MSM8996 specific PHY vreg list struct name to a genernal one as it is
used by all PHYs. Add a specific field to handle dual lane situation.
Signed-off-by: Can Guo
Reviewed-by: Evan Green
Reviewed-by: Manu Gautam
Reviewed-by: Vivek Gautam
---
From: Can Guo
Move MSM8996 specific PHY vreg list struct name to a genernal one as it is
used by all PHYs. Add a specific field to handle dual lane situation.
Signed-off-by: Can Guo
Reviewed-by: Evan Green
Reviewed-by: Manu Gautam
Reviewed-by: Vivek Gautam
---
On Thu, Sep 20, 2018 at 03:34:35PM -0700, Matthias Kaehlcke wrote:
> +EXPORT_SYMBOL(fwnode_get_bd_address);
EXPORT_SYMBOL_GPL()? That matches the majority in this file.
thanks,
greg k-h
On Thu, Sep 20, 2018 at 03:34:35PM -0700, Matthias Kaehlcke wrote:
> +EXPORT_SYMBOL(fwnode_get_bd_address);
EXPORT_SYMBOL_GPL()? That matches the majority in this file.
thanks,
greg k-h
On Tue, 2018-09-18 at 21:37 -0700, Manivannan Sadhasivam wrote:
> On Wed, Sep 19, 2018 at 10:54:10AM +0800, Sean Wang wrote:
> > On Tue, 2018-09-18 at 15:07 -0700, Linus Walleij wrote:
> > > On Sat, Sep 8, 2018 at 4:07 AM wrote:
> > >
> > > > v2 and changes since v1:
> > >
> > > I had trouble
On Tue, 2018-09-18 at 21:37 -0700, Manivannan Sadhasivam wrote:
> On Wed, Sep 19, 2018 at 10:54:10AM +0800, Sean Wang wrote:
> > On Tue, 2018-09-18 at 15:07 -0700, Linus Walleij wrote:
> > > On Sat, Sep 8, 2018 at 4:07 AM wrote:
> > >
> > > > v2 and changes since v1:
> > >
> > > I had trouble
> On Sep 20, 2018, at 8:45 PM, Andy Lutomirski wrote:
>
>
>
>> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior
>> wrote:
>>
>> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -101,14
> On Sep 20, 2018, at 8:45 PM, Andy Lutomirski wrote:
>
>
>
>> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior
>> wrote:
>>
>> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -101,14
From: Mars Cheng
Add NO_EINT_SUPPORT back to pinctrl-mtk-common-v2.h as the alias of
EINT_NA to indicate that some pin not capable of being controlled as eint
and that is required by pinctrl-paris based driver as old
pinctrl-mtk-common.h already had.
Signed-off-by: Mars Cheng
Signed-off-by:
From: Mars Cheng
Add NO_EINT_SUPPORT back to pinctrl-mtk-common-v2.h as the alias of
EINT_NA to indicate that some pin not capable of being controlled as eint
and that is required by pinctrl-paris based driver as old
pinctrl-mtk-common.h already had.
Signed-off-by: Mars Cheng
Signed-off-by:
From: Sean Wang
EINT_NA is an u16 number, so it should be U16_MAX instead of -1
to fix up drivers/pinctrl/mediatek/pinctrl-paris.c:732 mtk_gpio_to_irq()
warn: impossible condition (desc->eint.eint_n == -1) => (0-u16max == (-1))
Also happens in
drivers/pinctrl/mediatek/pinctrl-paris.c:749
From: ZH Chen
Add MT6765 pinctrl driver based on MediaTek pinctrl-paris core.
Signed-off-by: Mars Cheng
Signed-off-by: ZH Chen
Signed-off-by: Sean Wang
---
drivers/pinctrl/mediatek/Kconfig |7 +
drivers/pinctrl/mediatek/Makefile |1 +
From: Sean Wang
EINT_NA is an u16 number, so it should be U16_MAX instead of -1
to fix up drivers/pinctrl/mediatek/pinctrl-paris.c:732 mtk_gpio_to_irq()
warn: impossible condition (desc->eint.eint_n == -1) => (0-u16max == (-1))
Also happens in
drivers/pinctrl/mediatek/pinctrl-paris.c:749
From: ZH Chen
Add MT6765 pinctrl driver based on MediaTek pinctrl-paris core.
Signed-off-by: Mars Cheng
Signed-off-by: ZH Chen
Signed-off-by: Sean Wang
---
drivers/pinctrl/mediatek/Kconfig |7 +
drivers/pinctrl/mediatek/Makefile |1 +
From: Mars Cheng
Just add eint support to MT6765 pinctrl driver as usual as
happens on the other SoCs.
Signed-off-by: Mars Cheng
Signed-off-by: Sean Wang
---
drivers/pinctrl/mediatek/pinctrl-mt6765.c | 8
1 file changed, 8 insertions(+)
diff --git
From: Mars Cheng
Just add eint support to MT6765 pinctrl driver as usual as
happens on the other SoCs.
Signed-off-by: Mars Cheng
Signed-off-by: Sean Wang
---
drivers/pinctrl/mediatek/pinctrl-mt6765.c | 8
1 file changed, 8 insertions(+)
diff --git
> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior
> wrote:
>
> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
>>> --- a/arch/x86/kernel/fpu/core.c
>>> +++ b/arch/x86/kernel/fpu/core.c
>>> @@ -101,14 +101,14 @@ void __kernel_fpu_begin(void)
>>>
>>> kernel_fpu_disable();
>>>
> On Sep 19, 2018, at 10:05 AM, Sebastian Andrzej Siewior
> wrote:
>
> On 2018-09-12 08:47:19 [-0700], Andy Lutomirski wrote:
>>> --- a/arch/x86/kernel/fpu/core.c
>>> +++ b/arch/x86/kernel/fpu/core.c
>>> @@ -101,14 +101,14 @@ void __kernel_fpu_begin(void)
>>>
>>> kernel_fpu_disable();
>>>
Hello Rafael,
On Thu, Sep 20, 2018 at 1:06 PM Rafael J. Wysocki wrote:
>
> On Thu, Sep 20, 2018 at 7:43 AM Silesh C V wrote:
> >
> > Similar to bus_find_device_by_name, but finds the device having a
> > specific of_node.
>
> First, what do you need it for? Please describe your use case in the
Hello Rafael,
On Thu, Sep 20, 2018 at 1:06 PM Rafael J. Wysocki wrote:
>
> On Thu, Sep 20, 2018 at 7:43 AM Silesh C V wrote:
> >
> > Similar to bus_find_device_by_name, but finds the device having a
> > specific of_node.
>
> First, what do you need it for? Please describe your use case in the
On Fri, 21 Sep 2018 at 06:39, Tao Ren wrote:
>
> On 9/20/18, 8:46 AM, "Linus Walleij" wrote:
>
> > Actually this is much more intuitive too, it is the typical way to handle
> > a down-counting timer. Good catch!
> > Reviewed-by: Linus Walleij
>
> Thank you Linus for the quick review!
>
> >
On Fri, 21 Sep 2018 at 06:39, Tao Ren wrote:
>
> On 9/20/18, 8:46 AM, "Linus Walleij" wrote:
>
> > Actually this is much more intuitive too, it is the typical way to handle
> > a down-counting timer. Good catch!
> > Reviewed-by: Linus Walleij
>
> Thank you Linus for the quick review!
>
> >
Hi Jacek and Pavel,
On 11 September 2018 at 10:47, Baolin Wang wrote:
> This patch adds one new led trigger that LED device can configure
> the software or hardware pattern and trigger it.
>
> Consumers can write 'pattern' file to enable the software pattern
> which alters the brightness for the
Hi Jacek and Pavel,
On 11 September 2018 at 10:47, Baolin Wang wrote:
> This patch adds one new led trigger that LED device can configure
> the software or hardware pattern and trigger it.
>
> Consumers can write 'pattern' file to enable the software pattern
> which alters the brightness for the
/Keith-Busch/mm-faster-get-user-pages/20180920-184931
config: arm-oxnas_v6_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x
/Keith-Busch/mm-faster-get-user-pages/20180920-184931
config: arm-oxnas_v6_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x
Hi Keith,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc4 next-20180920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Keith,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc4 next-20180920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Friday, September 21, 2018 1:48 AM, Rik van Riel wrote:
> On Thu, 2018-09-20 at 03:14 +0100, Edward Cree wrote:
>
> > I think there are important differences between code to be run by
> > CPUs
> > and a Code to be run by humans. And when the author goes on a
> > victory
> > lap on Twitter and
On Friday, September 21, 2018 1:48 AM, Rik van Riel wrote:
> On Thu, 2018-09-20 at 03:14 +0100, Edward Cree wrote:
>
> > I think there are important differences between code to be run by
> > CPUs
> > and a Code to be run by humans. And when the author goes on a
> > victory
> > lap on Twitter and
On Thu, Sep 20, 2018 at 4:42 PM Tycho Andersen wrote:
>
> On Wed, Sep 19, 2018 at 12:58:20PM -0700, Andy Lutomirski wrote:
> > On Wed, Sep 19, 2018 at 7:38 AM, Tycho Andersen wrote:
> > > On Wed, Sep 19, 2018 at 07:19:56AM -0700, Andy Lutomirski wrote:
> > >>
> > >>
> > >> > On Sep 19, 2018, at
On Thu, Sep 20, 2018 at 4:42 PM Tycho Andersen wrote:
>
> On Wed, Sep 19, 2018 at 12:58:20PM -0700, Andy Lutomirski wrote:
> > On Wed, Sep 19, 2018 at 7:38 AM, Tycho Andersen wrote:
> > > On Wed, Sep 19, 2018 at 07:19:56AM -0700, Andy Lutomirski wrote:
> > >>
> > >>
> > >> > On Sep 19, 2018, at
On 20/09/2018 9:13 PM, Song Qiang wrote:
PNI RM3100 magnetometer is a high resolution, large signal immunity
magnetometer, composed of 3 single sensors and a processing chip.
PNI is currently not in the vendors list, so this is also adding it.
In the subject: Isn't the RM3100 a 3axis mag.
The
On 20/09/2018 9:13 PM, Song Qiang wrote:
PNI RM3100 magnetometer is a high resolution, large signal immunity
magnetometer, composed of 3 single sensors and a processing chip.
PNI is currently not in the vendors list, so this is also adding it.
In the subject: Isn't the RM3100 a 3axis mag.
The
On 09/12/18 at 08:31am, Ingo Molnar wrote:
> Would you like to work on this? These would be really nice additions, once
> the code is cleaned
> up to be maintainable and the pending bug fixes you have are merged.
>
> In terms of patch logistics I'd suggest this ordering:
>
> - documentation
On 09/12/18 at 08:31am, Ingo Molnar wrote:
> Would you like to work on this? These would be really nice additions, once
> the code is cleaned
> up to be maintainable and the pending bug fixes you have are merged.
>
> In terms of patch logistics I'd suggest this ordering:
>
> - documentation
--
Greetings,
I wish to seek your assistance for the transfer of US$35M depository
made by a politician for an investment programme that has
remained dormant for years now.I shall provide you with more details
and relevant documents that will help you understand the transaction.
Mr. Hama
--
Greetings,
I wish to seek your assistance for the transfer of US$35M depository
made by a politician for an investment programme that has
remained dormant for years now.I shall provide you with more details
and relevant documents that will help you understand the transaction.
Mr. Hama
On Thu, Sep 20, 2018 at 6:39 PM, John Johansen
wrote:
> On 09/20/2018 06:10 PM, Casey Schaufler wrote:
>> On 9/20/2018 5:45 PM, Kees Cook wrote:
>>> On Thu, Sep 20, 2018 at 5:25 PM, Casey Schaufler
>>> wrote:
On 9/20/2018 9:23 AM, Kees Cook wrote:
> config LSM_ORDER
> string
On Thu, Sep 20, 2018 at 6:39 PM, John Johansen
wrote:
> On 09/20/2018 06:10 PM, Casey Schaufler wrote:
>> On 9/20/2018 5:45 PM, Kees Cook wrote:
>>> On Thu, Sep 20, 2018 at 5:25 PM, Casey Schaufler
>>> wrote:
On 9/20/2018 9:23 AM, Kees Cook wrote:
> config LSM_ORDER
> string
On 9/20/18 5:36 PM, Linus Walleij wrote:
What I mean is that $SUBJECT patch might not hurt Qualcomms
GPIOs (not crash the platform) if and only if it is augmented to not
try to get the initial direction from lines masked off in .valid_mask
if .need_valid_mask is true.
Whether it makes sense
On 9/20/18 5:36 PM, Linus Walleij wrote:
What I mean is that $SUBJECT patch might not hurt Qualcomms
GPIOs (not crash the platform) if and only if it is augmented to not
try to get the initial direction from lines masked off in .valid_mask
if .need_valid_mask is true.
Whether it makes sense
fixes following Smatch static check warning:
./drivers/pinctrl/sunxi/pinctrl-sunxi.c:1112 sunxi_pinctrl_build_state()
warn: passing devm_ allocated variable to kfree. 'pctrl->functions'
As we will be calling krealloc() on pointer 'pctrl->functions', which means
kfree() will be called in there,
fixes following Smatch static check warning:
./drivers/pinctrl/sunxi/pinctrl-sunxi.c:1112 sunxi_pinctrl_build_state()
warn: passing devm_ allocated variable to kfree. 'pctrl->functions'
As we will be calling krealloc() on pointer 'pctrl->functions', which means
kfree() will be called in there,
The patch
regulator: da905{2,5}: Remove unnecessary array check
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
spi: pic32: Use proper enum in dmaengine_prep_slave_rg
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
regulator: da905{2,5}: Remove unnecessary array check
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
spi: pic32: Use proper enum in dmaengine_prep_slave_rg
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
debugfs_remove_recursive has taken the null pointer into account.
just remove the null check before debugfs_remove_recursive.
Acked-by: Masami Hiramatsu
Signed-off-by: zhong jiang
---
kernel/fail_function.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
debugfs_remove_recursive has taken the null pointer into account.
just remove the null check before debugfs_remove_recursive.
Acked-by: Masami Hiramatsu
Signed-off-by: zhong jiang
---
kernel/fail_function.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
This patch seems reasonable, but you emailed the wrong people :)
On Thu, Sep 20, 2018 at 5:15 PM Jason A. Donenfeld wrote:
>
> It turns out that KASAN in general will bloat stack frames in unexpected
> ways, not just KASAN_EXTRA. So, this patch trivially changes that
> default to be associated
This patch seems reasonable, but you emailed the wrong people :)
On Thu, Sep 20, 2018 at 5:15 PM Jason A. Donenfeld wrote:
>
> It turns out that KASAN in general will bloat stack frames in unexpected
> ways, not just KASAN_EXTRA. So, this patch trivially changes that
> default to be associated
Hi Guys,
Could you have a chance to review this patchset?
Thanks!
On Mon, Sep 17, 2018 at 09:44:49AM +0900, Minchan Kim wrote:
> To use bit 5 in page table as L_PTE_SPECIAL, we need a room for that.
> It seems we don't need 4 bits for the memory type with ARMv6+.
> If it's true, let's reorder
This driver has two module parameters that allow an override of the
checks for matching model and BIOS version. However, both parameters
expect you to choose an entry from the existing list of supported
systems, encoded within the driver itself.
Without the source, such as in a binary
I came across this older netbook over the xmas holidays, and noticed the
acerhdf driver wouldn't load. Turns out the BIOS string was too new,
and not listed in the driver. There were module params for overrides,
but I found their use isn't quite clear without reading the source.
Here I clarify
On Thu, 2018-09-20 at 03:14 +0100, Edward Cree wrote:
> I think there are important differences between code to be run by
> CPUs
> and a Code to be run by humans. And when the author goes on a
> victory
> lap on Twitter and declares the Code to be "a political document",
> is
> it any
Just like we avoid specifying actual block devices like sda for fdisk
and dd examples, we should not specify specific thermal zones here.
On the platform I was testing on, zone0 was acpitz, and zone1 was for
this acerhdf driver. Make the printk such that it won't work with a
blind cut-and-paste,
Hi Guys,
Could you have a chance to review this patchset?
Thanks!
On Mon, Sep 17, 2018 at 09:44:49AM +0900, Minchan Kim wrote:
> To use bit 5 in page table as L_PTE_SPECIAL, we need a room for that.
> It seems we don't need 4 bits for the memory type with ARMv6+.
> If it's true, let's reorder
This driver has two module parameters that allow an override of the
checks for matching model and BIOS version. However, both parameters
expect you to choose an entry from the existing list of supported
systems, encoded within the driver itself.
Without the source, such as in a binary
I came across this older netbook over the xmas holidays, and noticed the
acerhdf driver wouldn't load. Turns out the BIOS string was too new,
and not listed in the driver. There were module params for overrides,
but I found their use isn't quite clear without reading the source.
Here I clarify
On Thu, 2018-09-20 at 03:14 +0100, Edward Cree wrote:
> I think there are important differences between code to be run by
> CPUs
> and a Code to be run by humans. And when the author goes on a
> victory
> lap on Twitter and declares the Code to be "a political document",
> is
> it any
Just like we avoid specifying actual block devices like sda for fdisk
and dd examples, we should not specify specific thermal zones here.
On the platform I was testing on, zone0 was acpitz, and zone1 was for
this acerhdf driver. Make the printk such that it won't work with a
blind cut-and-paste,
unsubscribe linux-kernel
--
Best regards
Kassey
To fix:
acerhdf: unknown (unsupported) BIOS version Gateway /LT31 /v1.3307 ,
please report, aborting!
As can be seen in the context, the BIOS registers haven't changed in
the previous versions, so the assumption is they won't have changed
in this last update for this somewhat older
Hi Jiri
Can you pick up the patch?
Thanks
zhong jiang
On 2018/9/13 15:41, zhong jiang wrote:
> Fix the following compile warning:
>
> drivers/hid/hid-logitech-hidpp.c: In function 'hi_res_scroll_enable':
> drivers/hid/hid-logitech-hidpp.c:2714:54: warning: 'multiplier' may be used
>
Normally, a module parameter for a BIOS check override implies "pretend
you support this version" (and the user will enter their local version).
However, this driver uses the model/BIOS module parameters in a way that
is "pretend my system is the supported model XYZ with BIOS version ABC."
which
Hi Tejun
Thanks for your kindly response.
On 09/21/2018 04:53 AM, Tejun Heo wrote:
> Hello,
>
> On Thu, Sep 20, 2018 at 06:18:21PM +0800, Jianchao Wang wrote:
>> -static inline void percpu_ref_get_many(struct percpu_ref *ref, unsigned
>> long nr)
>> +static inline void
There is a table of Vendor/Model/Version {control data} in this driver,
but outside of the initial probe, the V/M/V is never used again, and
neither are any of the entries for platforms other than the one which
matches the running target.
By simply storing the {control data} for the matched
These three functions are only called from the probe code which is
already marked __init and hence these can be __init as well.
Cc: Peter Feuerer
Cc: Darren Hart
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
drivers/platform/x86/acerhdf.c | 6 +++---
1 file changed, 3 insertions(+),
unsubscribe linux-kernel
--
Best regards
Kassey
To fix:
acerhdf: unknown (unsupported) BIOS version Gateway /LT31 /v1.3307 ,
please report, aborting!
As can be seen in the context, the BIOS registers haven't changed in
the previous versions, so the assumption is they won't have changed
in this last update for this somewhat older
Hi Jiri
Can you pick up the patch?
Thanks
zhong jiang
On 2018/9/13 15:41, zhong jiang wrote:
> Fix the following compile warning:
>
> drivers/hid/hid-logitech-hidpp.c: In function 'hi_res_scroll_enable':
> drivers/hid/hid-logitech-hidpp.c:2714:54: warning: 'multiplier' may be used
>
Normally, a module parameter for a BIOS check override implies "pretend
you support this version" (and the user will enter their local version).
However, this driver uses the model/BIOS module parameters in a way that
is "pretend my system is the supported model XYZ with BIOS version ABC."
which
Hi Tejun
Thanks for your kindly response.
On 09/21/2018 04:53 AM, Tejun Heo wrote:
> Hello,
>
> On Thu, Sep 20, 2018 at 06:18:21PM +0800, Jianchao Wang wrote:
>> -static inline void percpu_ref_get_many(struct percpu_ref *ref, unsigned
>> long nr)
>> +static inline void
There is a table of Vendor/Model/Version {control data} in this driver,
but outside of the initial probe, the V/M/V is never used again, and
neither are any of the entries for platforms other than the one which
matches the running target.
By simply storing the {control data} for the matched
These three functions are only called from the probe code which is
already marked __init and hence these can be __init as well.
Cc: Peter Feuerer
Cc: Darren Hart
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
drivers/platform/x86/acerhdf.c | 6 +++---
1 file changed, 3 insertions(+),
Hi,
On Fri, Sep 21, 2018 at 04:08:28AM +0800, Baolin Wang wrote:
> Hi Sebastian,
>
> On 21 September 2018 at 00:58, Sebastian Reichel
> wrote:
> > [Dropped a couple of people from CC, added Baolin]
> >
> > Hi Craig, Baolin and Rob,
> >
> > On Thu, Sep 20, 2018 at 03:32:29PM +0100, Craig wrote:
On Thu, Sep 20, 2018 at 08:13:52PM +0100, Craig wrote:
> On 20 September 2018 17:58:47 BST, Sebastian Reichel
> wrote:
> >[Dropped a couple of people from CC, added Baolin]
> >
> >Hi Craig, Baolin and Rob,
> >
> >On Thu, Sep 20, 2018 at 03:32:29PM +0100, Craig wrote:
> >> On 16 September 2018
1 - 100 of 1302 matches
Mail list logo
