On 3/17/2021 4:02 PM, Kuppuswamy, Sathyanarayanan wrote:
> My point is, there is no race in OS handlers (pciehp_ist() vs
> pcie_do_recovery())
> However, Sinan wrote in
>> 2018 that one of the issues with hotplug versus DPC is that pciehp
>> may turn off slot power and thereby foil DPC recovery.
On 1/28/2021 6:39 PM, Bjorn Helgaas wrote:
> AFAICT, this thread petered out with no resolution.
>
> If the bandwidth change notifications are important to somebody,
> please speak up, preferably with a patch that makes the notifications
> disabled by default and adds a parameter to enable them
On 10/12/2020 1:13 AM, Kuppuswamy, Sathyanarayanan wrote:
> Hi Sinan,
>
> On 9/28/20 11:32 AM, Kuppuswamy, Sathyanarayanan wrote:
>>
>>
>> On 9/28/20 11:25 AM, Sinan Kaya wrote:
>>> On 9/28/2020 2:02 PM, Sinan Kaya wrote:
>>>> Since there is no st
* functions to reset slot before calling
> - * drivers' slot_reset callbacks?
> - */
> + pci_reset_bus(dev);
> status = PCI_ERS_RESULT_RECOVERED;
> pci_dbg(dev, "broadcast slot_reset message\n");
> pci_walk_bus(bus, report_slot_reset, );
>
Reviewed-by: Sinan Kaya
oncept.
Current fatal error handling is best effort.
There is no way to recover if link is down by the time we
reach to fatal error handling routine.
This change will make the solution more reliable.
Reviewed-by: Sinan Kaya
if (reset_link(dev) != PCI_ERS_RESULT_RECOVERED) {
> pci_warn(dev, "link reset failed\n");
> goto failed;
> + } else {
> + if (status == PCI_ERS_RESULT_DISCONNECT ||
> + status == PCI_ERS_RESULT_N
On 9/30/2020 3:05 AM, Ethan Zhao wrote:
> When uncorrectable error happens, AER driver and DPC driver interrupt
> handlers likely call
>
>pcie_do_recovery()
>->pci_walk_bus()
> ->report_frozen_detected()
>
> with pci_channel_io_frozen the same time.
We need some more data on this.
On 9/28/2020 2:02 PM, Sinan Kaya wrote:
> Since there is no state restoration for FATAL errors, I am wondering
> whether
> calls to ->error_detected(), ->mmio_enabled() and ->slot_reset() are
> required?
I also would like to ask someone closer to the spec language double
On 9/28/2020 1:15 PM, Kuppuswamy, Sathyanarayanan wrote:
> Since there is no state restoration for FATAL errors, I am wondering
> whether
> calls to ->error_detected(), ->mmio_enabled() and ->slot_reset() are
> required?
Good question,
Initially when we started, we were trying to handle both
On 9/28/2020 7:10 AM, Sinan Kaya wrote:
> On 9/27/2020 10:01 PM, Zhao, Haifeng wrote:
>> Sinan,
>>I explained the reason why locks don't protect this case in the patch
>> description part.
>> Write side and read side hold different semaphore and mutex.
>>
>
On 9/28/2020 7:17 AM, Sinan Kaya wrote:
> This should remove/rescan logic should be inside DPC's slot_reset()
> function BTW. Not here.
Correct function name is dpc_handler().
I hope I did not create confusion with slot_reset() that gets called for
each driver post recovery.
On 9/27/2020 10:43 PM, Kuppuswamy, Sathyanarayanan wrote:
>> 2. no bus reset on NON_FATAL error through AER driver path.
>> This already tells me that you need to split your change into
>> multiple patches.
>>
>> Let's talk about this too. bus reset should be triggered via
>> AER driver before
On 9/27/2020 10:43 PM, Kuppuswamy, Sathyanarayanan wrote:
> FATAL + no-hotplug - In this case, link will still be reseted. But
> currently driver state is not properly restored. So I attempted
> to restore it using pci_reset_bus().
>
> status = reset_link(dev);
> - if (status !=
On 9/27/2020 10:01 PM, Zhao, Haifeng wrote:
> Sinan,
>I explained the reason why locks don't protect this case in the patch
> description part.
> Write side and read side hold different semaphore and mutex.
>
I have been thinking about it some time but is there any reason why we
have to
On 9/26/2020 11:28 PM, Ethan Zhao wrote:
> diff --git a/drivers/pci/hotplug/pciehp_hpc.c
> b/drivers/pci/hotplug/pciehp_hpc.c
> index 53433b37e181..6f271160f18d 100644
> --- a/drivers/pci/hotplug/pciehp_hpc.c
> +++ b/drivers/pci/hotplug/pciehp_hpc.c
> @@ -710,8 +710,10 @@ static irqreturn_t
On 9/25/2020 2:16 PM, Kuppuswamy, Sathyanarayanan wrote:
>> One approach is to share the restore code between hotplug driver and
>> DPC driver.
>>
>> If this is a too involved change, DPC driver should restore state
>> when hotplug is not supported.
> Yes. we can add a condition for hotplug
On 9/25/2020 2:16 PM, Kuppuswamy, Sathyanarayanan wrote:
>>
>> If this is a too involved change, DPC driver should restore state
>> when hotplug is not supported.
> Yes. we can add a condition for hotplug capability check.
>>
>> DPC driver should be self-sufficient by itself.
>>
Sounds good.
>>>
On 9/25/2020 1:11 PM, Kuppuswamy, Sathyanarayanan wrote:
>> Why? Isn't DPC slot reset enough?
> It will do the reset at hardware level. But driver state is not
> cleaned up. So doing bus reset will restore both driver and
> hardware states.
I really don't like this. If hotplug driver is restoring
On 9/25/2020 1:11 AM, Kuppuswamy, Sathyanarayanan wrote:
>
>
> On 9/24/20 1:52 PM, Sinan Kaya wrote:
>> On 9/24/2020 12:06 AM, Kuppuswamy, Sathyanarayanan wrote:
>>
>> So, this is a matter of moving the save/restore logic from the hotplug
>> driver into common
On 9/24/2020 12:06 AM, Kuppuswamy, Sathyanarayanan wrote:
> For problem description, please check the following details
>
> Current pcie_do_recovery() implementation has following two issues:
>
> 1. Fatal (DPC) error recovery is currently broken for non-hotplug
> capable devices. Current fatal
On 9/23/2020 10:51 PM, Kuppuswamy, Sathyanarayanan wrote:
>>
>> I see. Can I assume that your system supports DPC?
>> DPC is supposed to recover the link via dpc_reset_link().
> Yes. But the affected device/drivers cleanup during error recovery
> is handled by hotplug handler. So we are facing
On 9/23/2020 10:04 PM, Kuppuswamy, Sathyanarayanan wrote:
>> AFAIK, DLLSC is a requirement not optional. Why is this not supported by
>> non-hotplug ports?
> Its required for hotplug capable ports. Please check PCIe spec v5.0 sec
> 6.7.3.3.
>
> The Data Link Layer State Changed event provides an
On 9/22/2020 7:44 PM, Kuppuswamy, Sathyanarayanan wrote:
>> here does the restore happen here? I.e., what function does this?
>
> DLLSC link down event will remove affected devices/drivers. And link up
> event
> will re-create all devices.
>
> on DLLSC link down event
> ->pciehp_ist()
>
On 6/18/2020 11:55 AM, Matt Jolly wrote:
> + pci_warn(dev, " device [%04x:%04x] error
> status/mask=%08x/%08x\n",
> + dev->vendor, dev->device,
> + info->status, info->mask);
> + } else {
> + pci_err(dev, " device
On 6/10/2020 4:00 AM, Zhangfei Gao wrote:
>> Why not set the eetlp_prefix_path bit from a PCI quirk? Unlike the stall
>> problem from the other thread, this one looks like a simple design
>> mistake
>> that can be fixed easily in future iterations of the platform: just set
>> the "End-End TLP
a_chan
> *dmach)
> kfree(mdesc);
> }
>
> - mchan->allocated = 0;
> + mchan->allocated = false;
> spin_unlock_irqrestore(>lock, irqflags);
> }
Acked By: Sinan Kaya
On 4/28/2020 1:21 PM, Dan Carpenter wrote:
> What I meant to say here was:
>
> if (msi) {
> rc = hidma_request_msi(dmadev, pdev);
> if (rc)
> msi = false;
>
> Otherwise we end up checking freeing the msi in the error handling
> code when we
On 4/28/2020 8:54 AM, Dan Carpenter wrote:
>> @@ -897,7 +897,6 @@ static int hidma_probe(struct platform_device *pdev)
>> if (msi)
> ^^^
> This test doesn't work. It will call free hidma_free_msis() if the
> hidma_request_msi() call fails. We should do:
>
> if (msi) {
>
On 8/19/2019 4:56 AM, Mika Westerberg wrote:
>> There are PCI controllers that won't report presence detect correctly,
>> but still report link active.
> If that's the case then pciehp_card_present() returns false so we call
> pciehp_check_link_active() which should work with those controllers.
>
On 8/12/2019 10:31 AM, Mika Westerberg wrote:
> +int pciehp_card_present_or_link_active(struct controller *ctrl)
> {
> - return pciehp_card_present(ctrl) || pciehp_check_link_active(ctrl);
> + int ret;
> +
> + ret = pciehp_card_present(ctrl);
> + if (ret)
> + return
On 7/16/2019 7:35 AM, Robin Murphy wrote:
> On 15/07/2019 16:17, Sinan Kaya wrote:
>> On 7/15/2019 1:43 AM, Fuqian Huang wrote:
>>> Should I rewrite the commit log? Just mention that dma_alloc_coherent
>>> has already
>>> zeroed the memory and not to referenc
On 7/16/2019 12:04 AM, Sasha Levin wrote:
> ACPI_IORT lost it's explicit dependency on PCI in c6bb8f89fa6df
> ("ARM64/irqchip: Update ACPI_IORT symbol selection logic") where the
> author has relied on the general dependency of ACPI on PCI.
>
> However, that dependency was finally removed in
On 7/15/2019 1:43 AM, Fuqian Huang wrote:
> Should I rewrite the commit log? Just mention that dma_alloc_coherent
> has already
> zeroed the memory and not to reference the commit?
I'd like to hear from Robin Murphy that arm smmu driver follows this as
well.
On 7/14/2019 11:17 PM, Fuqian Huang wrote:
> In commit 518a2f1925c3
> ("dma-mapping: zero memory returned from dma_alloc_*"),
> dma_alloc_coherent has already zeroed the memory.
> So memset is not needed.
>
> Signed-off-by: Fuqian Huang
I don't see SWIO or ARM64 IOMMU drivers getting impacted
; debugfs_remove_recursive(dmadev->debugfs);
> Is that a problem?
I just wanted to double check. You probably want to remove the return
value on debugfs_create_file() to prevent others from doing the same
thing.
Acked-by: Sinan Kaya
the file dentry, remove the
> variables that were saving them as they were never even being used once
> set.
>
> Cc: Sinan Kaya
> Cc: Andy Gross
> Cc: David Brown
> Cc: Dan Williams
> Cc: Vinod Koul
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vg
On 4/29/2019 10:51 AM, Alex Williamson wrote:
So where do we go from here? I agree that dmesg is not necessarily a
great choice for these sorts of events and if they went somewhere else,
maybe I wouldn't have the same concerns about them generating user
confusion or contributing to DoS vectors
On 4/14/2019 11:55 PM, Kees Cook wrote:
Thanks! This looks good to me. For the series:
Reviewed-by: Kees Cook
Andrew, can you take these from lkml, or should the series get resent
directly to you? I think you might be the best to carry this?
Where do we stand on this?
Anything for me to do,
CONFIG_DEBUG_KERNEL should not impact code generation. Use the newly
defined CONFIG_DEBUG_MISC instead to keep the current code.
Signed-off-by: Sinan Kaya
Reviewed-by: Josh Triplett
---
arch/mips/kernel/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips
CONFIG_DEBUG_KERNEL should not impact code generation. Use the newly
defined CONFIG_DEBUG_MISC instead to keep the current code.
Signed-off-by: Sinan Kaya
Reviewed-by: Josh Triplett
---
arch/xtensa/include/asm/irqflags.h | 2 +-
arch/xtensa/kernel/smp.c | 2 +-
2 files changed, 2
ption but isn't"), make it depend on DEBUG_KERNEL and be
"default DEBUG_KERNEL" but allow itself to be turned off, and then
mechanically change the small handful of "#ifdef CONFIG_DEBUG_KERNEL" to
"#ifdef CONFIG_DEBUG_MISC".
Diff from v4:
- collect reviewed-by
- collect
_DEBUG_KERNEL" to
"#ifdef CONFIG_DEBUG_MISC".
Signed-off-by: Sinan Kaya
Reviewed-by: Josh Triplett
---
lib/Kconfig.debug | 9 +
1 file changed, 9 insertions(+)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 0d9e81779e37..0103a092ce3d 100644
--- a/lib/Kconfig
CONFIG_DEBUG_KERNEL should not impact code generation. Use the newly
defined CONFIG_DEBUG_MISC instead to keep the current code.
Signed-off-by: Sinan Kaya
Reviewed-by: Josh Triplett
---
arch/powerpc/kernel/sysfs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch
On 4/12/2019 12:05 AM, Josh Triplett wrote:
Can you point to the typo?
I did, in my response to the patch itself:
s/Miscellaneous/miscellaneous/ in the new option's description, since it
isn't at the start of a sentence.
Thanks, your emails arrived out of order. I got them now.
On 4/11/2019 11:02 PM, Josh Triplett wrote:
I noticed one minor typo in patch 1/5, with that fixed, for the whole
series:
Can you point to the typo?
CONFIG_DEBUG_KERNEL should not impact code generation. Use the newly
defined CONFIG_DEBUG_MISC instead to keep the current code.
Signed-off-by: Sinan Kaya
---
arch/xtensa/include/asm/irqflags.h | 2 +-
arch/xtensa/kernel/smp.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions
CONFIG_DEBUG_KERNEL should not impact code generation. Use the newly
defined CONFIG_DEBUG_MISC instead to keep the current code.
Signed-off-by: Sinan Kaya
---
arch/mips/kernel/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel
_DEBUG_KERNEL" to
"#ifdef CONFIG_DEBUG_MISC".
Signed-off-by: Sinan Kaya
---
lib/Kconfig.debug | 9 +
1 file changed, 9 insertions(+)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 0d9e81779e37..2f80ebaa6d9a 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
ption but isn't"), make it depend on DEBUG_KERNEL and be
"default DEBUG_KERNEL" but allow itself to be turned off, and then
mechanically change the small handful of "#ifdef CONFIG_DEBUG_KERNEL" to
"#ifdef CONFIG_DEBUG_MISC".
Sinan Kaya (5):
init: Introd
On 4/11/2019 6:21 PM, Kees Cook wrote:
Proposed alternative plan: let's add a new symbol, something like
DEBUG_MISC ("Miscellaneous debug code that should be under a more
specific debug option but isn't"), make it depend on DEBUG_KERNEL and be
"default DEBUG_KERNEL" but allow itself to be turned
On 4/11/2019 1:48 AM, Masahiro Yamada wrote:
I was going by what Kconfig tells me
Symbol: KALLSYMS_ALL [=n]
Depends on: DEBUG_KERNEL [=n] && KALLSYMS [=y]
Lots of features have 'depends on DEBUG_KERNEL'.
What is special about KALLSYMS_ALL here?
I had to do some learning about
On 4/11/2019 1:31 AM, Masahiro Yamada wrote:
t looks like CONFIG_KALLSYMS_ALL is the only feature that
requires CONFIG_DEBUG_KERNEL.
Which part of KALLSYMS_ALL code requires CONFIG_DEBUG_KERNEL?
I was going by what Kconfig tells me
Symbol: KALLSYMS_ALL [=n]
Depends on: DEBUG_KERNEL [=n] &&
On 4/10/2019 11:02 PM, Josh Triplett wrote:
Then let's fix*that*, and get checkpatch to help enforce it in the future.
EXPERT doesn't affect code generation, and neither should this.
I think we have to do both. We need to go after the users as well as
solve the immediate problem per this
CONFIG_DEBUG_KERNEL.
Select CONFIG_EXPERT when CONFIG_DEBUG_KERNEL is chosen but
you can still choose CONFIG_EXPERT without CONFIG_DEBUG_KERNEL.
Signed-off-by: Sinan Kaya
Reviewed-by: Kees Cook
---
init/Kconfig | 2 --
lib/Kconfig.debug | 1 +
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git
CONFIG_DEBUG_KERNEL.
Select CONFIG_EXPERT when CONFIG_DEBUG is chosen but you can
still choose CONFIG_EXPERT without CONFIG_DEBUG.
Signed-off-by: Sinan Kaya
---
init/Kconfig | 2 --
lib/Kconfig.debug | 1 +
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index
On 4/10/2019 6:28 PM, Kees Cook wrote:
diff --git a/init/Kconfig b/init/Kconfig
index c9386a365eea..7ce4a60ab3e9 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1188,8 +1188,6 @@ config BPF
menuconfig EXPERT
bool "Configure standard kernel features (expert users)"
- # Unhide
On 4/10/2019 6:21 PM, Kees Cook wrote:
I can go after individual enables if you agree assuming Mathieu will
go after the changes in the other email. Let me know otherwise.
How about you split it, but make DEBUG_KERNEL be "default EXPERT" that
way enabling EXPERT will enable DEBUG_KERNEL still
On 4/10/2019 6:04 PM, Kees Cook wrote:
I don't want any of the debug features in my kernel but still
need all the expert features. My kernel is considered a production
kernel. I don't really want to ship all the good debug enables.
Production kernels enable it. e.g. Ubuntu:
$ grep
On 4/10/2019 5:45 PM, Kees Cook wrote:
On Wed, Apr 10, 2019 at 2:26 PM Sinan Kaya wrote:
We can't seem to have a kernel with CONFIG_EXPERT set but
CONFIG_DEBUG_KERNEL unset these days.
While some of the features under the CONFIG_EXPERT require
CONFIG_DEBUG_KERNEL, it doesn't apply for all
like CONFIG_KALLSYMS_ALL is the only feature that
requires CONFIG_DEBUG_KERNEL. Move the CONFIG_DEBUG_KERNEL
selection to where it really is needed.
Signed-off-by: Sinan Kaya
---
init/Kconfig | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index
nt.
Fixes: b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage with
device_lock()")
Signed-off-by: Alex Williamson
---
Reviewed-by: Sinan Kaya
On 2/11/2019 2:15 PM, Raj, Ashok wrote:
It seems rather odd we have to check for ATS version.
I always assumed unspecified bits (Reserved) must be 0. We only check
this if ATS is enabled, and this particular bit wasn't given away for another
feature.
Is it really required to check for ATS
On 2/8/2019 8:02 PM, sathyanarayanan kuppuswamy wrote:
This means that you should probably have some kind of version check
here.
There is no version field in ATS v1.0 spec. Also, If I follow the
history log in PCI spec, I think ATS if first added at v1.2. Please
correct me if I am wrong.
On 2/7/2019 5:16 PM, sathyanarayanan kuppuswamy wrote:
If I remember this right, aligned request is only supported on ATS v1.1
but not supported on v1.0.
Its added in v1.1.
This means that you should probably have some kind of version check
here.
On 2/7/2019 1:41 PM, sathyanarayanan.kuppusw...@linux.intel.com wrote:
+ * As per PCI spec, If page aligned request bit is set, it indicates
+ * the untranslated address is always aligned to a 4096 byte boundary.
+ */
+int pci_ats_page_aligned(struct pci_dev *pdev)
+{
+ u16 cap;
+
+
On 2/1/2019 4:52 PM, Bjorn Helgaas wrote:
See https://bugzilla.kernel.org/show_bug.cgi?id=202425.
Robert bisected a problem with a 3ware 9650SE-2LP controller to
60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported") and
verified that reverting it solves the problem.
We have found
:
WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
Selected by [y]:
- SAMSUNG_Q10 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y]
Signed-off-by: Sinan Kaya
---
drivers/pl
: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
Selected by [y]:
- ACPI_CMPC [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y] &&
INPUT [=y] && (RFKILL [
:
WARNING: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
Selected by [y]:
- SAMSUNG_Q10 [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y]
Signed-off-by: Sinan Kaya
---
driver
: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE
Depends on [n]: HAS_IOMEM [=y] && BACKLIGHT_LCD_SUPPORT [=n]
Selected by [y]:
- ACPI_CMPC [=y] && X86 [=y] && X86_PLATFORM_DEVICES [=y] && ACPI [=y] &&
INPUT [=y] && (RFKILL [
On 1/24/2019 5:52 AM, Rafael J. Wysocki wrote:
Andy/Darren, these two seem to be for you, but I can take them too as
related to ACPI tagentially, so please let me know.
I'll post V2 to fix a "fat-finger" in summary. I was hoping to receive a
feedback until now.
I'll get the V2 out.
On 1/24/2019 5:51 AM, Rafael J. Wysocki wrote:
Is anyone taking this or should I?
Nobody replied to this yet. I was hoping this series to go through acpi
tree like the rest of the other fixes.
On 1/24/2019 5:51 AM, Rafael J. Wysocki wrote:
Is anyone taking this or should I?
This got applied:
https://git.kernel.org/tip/625210cfa6c0c26ea422f655bf68288176f174e6
Commit-ID: 625210cfa6c0c26ea422f655bf68288176f174e6
Gitweb: https://git.kernel.org/tip/625210cfa6c0c26ea422f655bf68288176f174e6
Author: Sinan Kaya
AuthorDate: Mon, 21 Jan 2019 23:19:58 +
Committer: Borislav Petkov
CommitDate: Tue, 22 Jan 2019 17:06:28 +0100
x86/Kconfig: Select
On 1/22/2019 11:17 AM, Kalle Valo wrote:
Sinan Kaya writes:
On 1/22/2019 5:15 AM, Luciano Coelho wrote:
On Mon, 2019-01-21 at 23:31 +, Sinan Kaya wrote:
There is an unresolved dependency as follows:
IWLWIFI_LEDS selects MAC80211_LEDS.
MAC80211_LEDS depends on MAC80211.
It is possible
On 1/22/2019 5:15 AM, Luciano Coelho wrote:
On Mon, 2019-01-21 at 23:31 +, Sinan Kaya wrote:
There is an unresolved dependency as follows:
IWLWIFI_LEDS selects MAC80211_LEDS.
MAC80211_LEDS depends on MAC80211.
It is possible to choose MAC80211_LEDS (y) but not choose MAC80211
(n)
WARNING
On 1/22/19, Borislav Petkov wrote:
> On Mon, Jan 21, 2019 at 11:19:58PM +0000, Sinan Kaya wrote:
>> After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without
>> CONFIG_PCI set")' dependencies on CONFIG_PCI that previously were
>> satisfied
y into IWLWIFI_LEDS so that we avoid this
configuration.
Signed-off-by: Sinan Kaya
---
drivers/net/wireless/intel/iwlwifi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig
b/drivers/net/wireless/intel/iwlwifi/Kconfig
index 49
his properly.
Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya
---
drivers/mfd/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f461460a2aeb..76f9909cf396 1
s not been
mentioned in the Kconfig.
Add an explicit dependency here.
Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/ar
On 1/18/2019 6:45 AM, Rafael J. Wysocki wrote:
On Thu, Jan 17, 2019 at 11:10 PM Borislav Petkov wrote:
On Thu, Jan 17, 2019 at 11:05:43PM +0100, Rafael J. Wysocki wrote:
I have patches for intel_ips and intel_pmc_ipc queued up (will be
pushed for -rc3), plus some others.
Yeah, I saw the
On 1/21/2019 5:46 PM, Sinan Kaya wrote:
ACPI_CMPC selects BACKLIGHT_LCD_SUPPORT but BACKLIGHT_LCD_SUPPORT
depends on BACKLIGHT_LCD_SUPPORT.
This should have been:
ACPI_CMPC selects BACKLIGHT_CLASS_DEVICE but BACKLIGHT_CLASS_DEVICE
depends on BACKLIGHT_LCD_SUPPORT.
Add BACKLIGHT_LCD_SUPPORT for ACPI_CMPC to fix the
warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE.
ACPI_CMPC selects BACKLIGHT_LCD_SUPPORT but BACKLIGHT_LCD_SUPPORT
depends on BACKLIGHT_LCD_SUPPORT.
Copy this dependency into ACPI_CMPC.
Signed-off-by: Sinan Kaya
Add BACKLIGHT_LCD_SUPPORT for SAMSUNG_Q10 to fix the
warning: unmet direct dependencies detected for BACKLIGHT_CLASS_DEVICE.
SAMSUNG_Q10 selects BACKLIGHT_LCD_SUPPORT but BACKLIGHT_LCD_SUPPORT
depends on BACKLIGHT_LCD_SUPPORT.
Copy this dependency into SAMSUNG_Q10.
Signed-off-by: Sinan Kaya
On 1/17/2019 5:09 PM, Borislav Petkov wrote:
On Thu, Jan 17, 2019 at 11:05:43PM +0100, Rafael J. Wysocki wrote:
I have patches for intel_ips and intel_pmc_ipc queued up (will be
pushed for -rc3), plus some others.
Yeah, I saw the patchset and applied some of them locally so that I be
able to
On 1/17/2019 11:37 AM, Borislav Petkov wrote:
Also, I see a lot of build failures when doing randconfig builds for the
stuff in drivers/platform/x86/Kconfig. Is someone picking those up too?
Can you share the build failures you are seeing?
On 1/17/2019 11:37 AM, Borislav Petkov wrote:
On Thu, Jan 17, 2019 at 04:17:22PM +, Sinan Kaya wrote:
After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without
CONFIG_PCI set")' dependencies on CONFIG_PCI that previously were
satisfied implicitly through de
s not been
mentioned in the Kconfig.
Add an explicit dependency here.
Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya
---
arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/ar
Hi,
On 1/16/2019 12:00 PM, Randy Dunlap wrote:
On 1/15/19 10:38 PM, Stephen Rothwell wrote:
Hi all,
Changes since 20190115:
on x86_64:
when CONFIG_PCI is not enabled (via randconfig):
WARNING: unmet direct dependencies detected for PCI_LOCKLESS_CONFIG
Depends on [n]: PCI [=n]
On 1/15/2019 3:55 PM, Stephen Rothwell wrote:
[I am experimenting with checking the Fixes tags in commits in linux-next.
Please let me know if you think I am being too strict.]
Hi Rafael,
Commits
62b33d57c534 ("drivers: thermal: int340x_thermal: Make PCI dependency
explicit")
Commit-ID: 5962dd22f0ff6f7d72fff974b3c637d52586643e
Gitweb: https://git.kernel.org/tip/5962dd22f0ff6f7d72fff974b3c637d52586643e
Author: Sinan Kaya
AuthorDate: Wed, 2 Jan 2019 18:10:37 +
Committer: Borislav Petkov
CommitDate: Fri, 11 Jan 2019 19:32:22 +0100
x86/intel/lpss: Make PCI
On 1/8/19, Paul Menzel wrote:
> Dear Maarten,
>
>
> Thank you very much for the quick response.
>
> On 01/08/19 16:37, Maarten Lankhorst wrote:
>> Op 08-01-2019 om 16:07 schreef Paul Menzel:
>
>>> Building Linux 5.0-rc1 fails with the errors below. Please find the
>>> configuration file attached.
On Tue, Jan 8, 2019 at 6:58 AM Zhang Rui wrote:
>
> On 一, 2019-01-07 at 12:19 +0100, Rafael J. Wysocki wrote:
> > On Sat, Jan 5, 2019 at 11:06 AM Sinan Kaya wrote:
> > >
> > >
> > > After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built
> &
On Mon, Jan 7, 2019 at 7:19 AM Mark Brown wrote:
>
> On Mon, Jan 07, 2019 at 12:15:35PM +0100, Rafael J. Wysocki wrote:
> > On Sat, Jan 5, 2019 at 11:06 AM Sinan Kaya wrote:
>
> > > Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without
> > > CONFI
On Mon, Jan 7, 2019 at 6:15 AM Rafael J. Wysocki wrote:
>
> On Sat, Jan 5, 2019 at 11:06 AM Sinan Kaya wrote:
> >
> > After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without
> > CONFIG_PCI set")' dependencies on CONFIG_PCI that previously wer
dependency on CONFIG_PCI.
Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya
---
drivers/thermal/intel/int340x_thermal/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/intel/int340x_thermal/Kconfi
ndency has not been explicitly called out.
Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya
Reviewed-by: Andy Shevchenko
Acked-by: Andy Shevchenko
---
drivers/platform/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 del
et")
Signed-off-by: Sinan Kaya
---
drivers/acpi/Makefile | 3 ++-
drivers/acpi/internal.h | 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 7c6afc111d76..bb857421c2e8 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/ac
This driver depends on the PCI infrastructure but the dependency has not
been explicitly called out.
Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya
Reviewed-by: Lukas Wunner
Acked-by: Daniel Vetter
---
drivers/gpu/vga/K
his reason, add a direct dependency on CONFIG_PCI to the
IOSF_MBI driver.
Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya
---
sound/soc/intel/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/i
1 - 100 of 3380 matches
Mail list logo
