Only field renaming. No functional change intended.
Signed-off-by: Rajat Jain
---
drivers/iommu/dma-iommu.c | 2 +-
drivers/iommu/intel/iommu.c | 2 +-
drivers/iommu/iommu.c | 2 +-
drivers/pci/ats.c | 2 +-
drivers/pci/pci.c | 2 +-
drivers/pci/
Hello Hans,
On Mon, Jul 6, 2020 at 5:50 PM Rajat Jain wrote:
>
> Hello Hans,
>
> On Mon, Jul 6, 2020 at 5:51 AM Hans de Goede wrote:
> >
> > Hi,
> >
> > On 3/12/20 7:56 PM, Rajat Jain wrote:
> > > Add support for an ACPI based integrated privacy s
On Wed, Oct 28, 2020 at 3:07 PM Rajat Jain wrote:
>
> On Wed, Oct 28, 2020 at 2:52 PM Bjorn Helgaas wrote:
> >
> > [+cc Rajat, LKML]
> >
>
> Thanks for copying me. (I don't look at mailing lists actively - so
> missed this). Taking a look at this now.
>
> T
-random email address (typo)
are of in the quirks, in the other direction
i.e. when checking if the ACS is enabled or not. So no need to do
anything there.
Reported-by: Boris V
Fixes: 52fbf5bdeeef ("PCI: Cache ACS capability offset in device")
Signed-off-by: Rajat Jain
---
drivers/pci/pci.c | 9 +++--
1 fi
> > > 08:04.0 PCI bridge [0604]: ASMedia Technology Inc. Device
> > > [1b21:118f]
> > > 09:00.0 Ethernet controller [0200]: Intel Corporation I211
> > > Gigabit Network Connection [8086:1539] (rev 03)
> > > 0c:00.0 SATA controller
hardwaj
> Cc: Vishwanath Somayaji
> Cc: Darren Hart
> Cc: Andy Shevchenko
> Cc: Rajat Jain
> Cc: platform-driver-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Reported-by: Maximilian Luz
> Fixes: b02f6a2ef0a1 ("platform/x86: intel_pmc_core: Attach
Hello Bjorn,
On Tue, Jul 14, 2020 at 1:19 PM Rajat Jain wrote:
>
> On Sat, Jul 11, 2020 at 12:53 PM Bjorn Helgaas wrote:
> >
> > On Fri, Jul 10, 2020 at 03:53:59PM -0700, Rajat Jain wrote:
> > > On Fri, Jul 10, 2020 at 2:29 PM Raj, Ashok wrote:
> > > > O
Hello Bjorn,
On Mon, Aug 17, 2020 at 3:50 PM Rajat Jain wrote:
>
> Hello Bjorn,
>
>
> On Sat, Aug 1, 2020 at 5:30 PM Rajat Jain wrote:
> >
> > Hi Bjorn,
> >
> >
> > On Tue, Jul 14, 2020 at 1:24 PM Rajat Jain wrote:
> > >
&
Hello Bjorn,
On Sat, Aug 1, 2020 at 5:30 PM Rajat Jain wrote:
>
> Hi Bjorn,
>
>
> On Tue, Jul 14, 2020 at 1:24 PM Rajat Jain wrote:
> >
> > On Tue, Jul 14, 2020 at 1:15 PM Rajat Jain wrote:
> > >
> > > The ACS "Translation Blocking" bit
Hi Bjorn,
On Tue, Jul 14, 2020 at 1:24 PM Rajat Jain wrote:
>
> On Tue, Jul 14, 2020 at 1:15 PM Rajat Jain wrote:
> >
> > The ACS "Translation Blocking" bit blocks the translated addresses from
> > the devices. We don't expect such traffic from devices
On Tue, Jul 14, 2020 at 1:15 PM Rajat Jain wrote:
>
> The ACS "Translation Blocking" bit blocks the translated addresses from
> the devices. We don't expect such traffic from devices unless ATS is
> enabled on them. A device sending such traffic without ATS enabled,
> i
On Sat, Jul 11, 2020 at 12:53 PM Bjorn Helgaas wrote:
>
> On Fri, Jul 10, 2020 at 03:53:59PM -0700, Rajat Jain wrote:
> > On Fri, Jul 10, 2020 at 2:29 PM Raj, Ashok wrote:
> > > On Fri, Jul 10, 2020 at 03:29:22PM -0500, Bjorn Helgaas wrote:
> > > > On Tue, Jul 07
by default for all devices, and it stays enabled until
atleast one of the devices downstream wants to enable ATS. It gets
disabled to enable ATS on a device downstream it, and then gets enabled
back on once all the downstream devices don't need ATS.
Signed-off-by: Rajat Jain
---
Note that I'
On Sat, Jul 11, 2020 at 12:53 PM Bjorn Helgaas wrote:
>
> On Fri, Jul 10, 2020 at 03:53:59PM -0700, Rajat Jain wrote:
> > On Fri, Jul 10, 2020 at 2:29 PM Raj, Ashok wrote:
> > > On Fri, Jul 10, 2020 at 03:29:22PM -0500, Bjorn Helgaas wrote:
> > > > On Tue, Jul 07
Hello,
On Fri, Jul 10, 2020 at 2:29 PM Raj, Ashok wrote:
>
> Hi Bjorn
>
>
> On Fri, Jul 10, 2020 at 03:29:22PM -0500, Bjorn Helgaas wrote:
> > On Tue, Jul 07, 2020 at 03:46:04PM -0700, Rajat Jain wrote:
> > > When enabling ACS, enable translation bloc
kernel.org/linux-pci/20200610230906.GA1528594@bjorn-Precision-5520/
Signed-off-by: Rajat Jain
---
v4: No change
v3: * fix commit log and minor code comment
* Don't check for "ExternalFacingPort" on PCI_EXP_TYPE_DOWNSTREAM
* Check only for pdev->external_facing in iommu.c
v2: cosmeti
When enabling ACS, enable translation blocking for external facing ports
and untrusted devices.
Signed-off-by: Rajat Jain
---
v4: Add braces to avoid warning from kernel robot
print warning for only external-facing devices.
v3: print warning if ACS_TB not supported on external-facing
Move pci_enable_acs() and the functions it depends on, further up in the
source code to avoid having to forward declare it when we make it static
in near future (next patch).
No functional changes intended.
Signed-off-by: Rajat Jain
---
v4: Same as v3
v3: Initial version of the patch, created
Currently ACS capabiity is being looked up at a number of places. Read and
store it once at bootup so that it can be used by all later.
Signed-off-by: Rajat Jain
---
v4: No change
v3: fix commit log, remove forward declation of static function
v2: Commit log cosmetic changes
drivers/pci
On Wed, Jul 1, 2020 at 10:23 PM Oliver O'Halloran wrote:
>
> On Thu, Jul 2, 2020 at 4:07 AM Rajat Jain wrote:
> >
> > *snip*
> >
> > > > I guess it would make sense to have an attribute for user space to
> > > > write to in order to make the ke
When enabling ACS, enable translation blocking for external facing ports
and untrusted devices.
Signed-off-by: Rajat Jain
---
v3: print warning if ACS_TB not supported on external-facing/untrusted ports.
Minor code comments fixes.
v2: Commit log change
drivers/pci/pci.c| 7
Move pci_enable_acs() and the functions it depends on, further up in the
source code to avoid having to forward declare it when we make it static
in near future (next patch).
No functional changes intended.
Signed-off-by: Rajat Jain
---
v3: Initial version of the patch, created per Bjorn's
kernel.org/linux-pci/20200610230906.GA1528594@bjorn-Precision-5520/
Signed-off-by: Rajat Jain
---
v3: * fix commit log and minor code comment
* Don't check for "ExternalFacingPort" on PCI_EXP_TYPE_DOWNSTREAM
* Check only for pdev->external_facing in iommu.c
v2: cosmetic changes in
Currently ACS capabiity is being looked up at a number of places. Read and
store it once at bootup so that it can be used by all later.
Signed-off-by: Rajat Jain
---
v3: fix commit log, remove forward declation of static function
v2: Commit log cosmetic changes
drivers/pci/p2pdma.c | 2
Hello Hans,
On Mon, Jul 6, 2020 at 5:51 AM Hans de Goede wrote:
>
> Hi,
>
> On 3/12/20 7:56 PM, Rajat Jain wrote:
> > Add support for an ACPI based integrated privacy screen that is
> > available on some systems.
> >
> > Signed-off-by: Rajat Jain
>
&g
Hello Bjorn,
On Mon, Jul 6, 2020 at 4:30 PM Bjorn Helgaas wrote:
>
> On Mon, Jul 06, 2020 at 03:31:47PM -0700, Rajat Jain wrote:
> > On Mon, Jul 6, 2020 at 9:38 AM Bjorn Helgaas wrote:
> > > On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
&
On Tue, Jun 30, 2020 at 1:02 AM Greg Kroah-Hartman
wrote:
>
> On Mon, Jun 29, 2020 at 09:49:40PM -0700, Rajat Jain wrote:
> > device_attach() returning failure indicates a driver error while trying to
> > probe the device. In such a scenario, the PCI device should still be added
lways")
Signed-off-by: Rajat Jain
Reviewed-by: Greg Kroah-Hartman
---
Resending to stable, independent from other patches per Greg's suggestion
v2: Add Greg's reviewed by, fix commit log
drivers/pci/bus.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/pci/bus.c
On Mon, Jul 6, 2020 at 10:07 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:39PM -0700, Rajat Jain wrote:
> > When enabling ACS, enable translation blocking for external facing ports
> > and untrusted devices.
> >
> > Signed-off-by: Rajat Jain
>
On Mon, Jul 6, 2020 at 9:45 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:39PM -0700, Rajat Jain wrote:
> > When enabling ACS, enable translation blocking for external facing ports
> > and untrusted devices.
> >
> > Signed-off-by: Rajat Jain
>
Hello,
On Mon, Jul 6, 2020 at 9:38 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
> > The "ExternalFacing" devices (root ports) are still internal devices that
> > sit on the internal system fabric and thus trusted. Currentl
On Sat, Jul 4, 2020 at 4:44 AM Pavel Machek wrote:
>
> Hi!
>
> > * The first 3 patches tighten the PCI security using ACS, and take care
> > of a border case.
> > * The 4th patch takes care of PCI bug.
> > * 5th and 6th patches expose a device's location into the sysfs to allow
> > admin to
Hi Bjorn,
Thanks for taking a look.
On Mon, Jul 6, 2020 at 8:58 AM Bjorn Helgaas wrote:
>
> On Mon, Jun 29, 2020 at 09:49:37PM -0700, Rajat Jain wrote:
> > Currently this is being looked up at a number of places. Read and store it
> > once at bootup so that it can be
:34PM +0200, Rafael J. Wysocki wrote:
> > > > On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
> > > > wrote:
> > > > >
> > > > > On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> > > > > > On Mon, Jun 29, 2020 at
lways")
Signed-off-by: Rajat Jain
Reviewed-by: Greg Kroah-Hartman
---
v2: Cosmetic change in commit log.
Add Greg's "reviewed-by"
drivers/pci/bus.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 8e40b3e6da77d..
When enabling ACS, enable translation blocking for external facing ports
and untrusted devices.
Signed-off-by: Rajat Jain
---
v2: Commit log change
drivers/pci/pci.c| 4
drivers/pci/quirks.c | 11 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/pci.c b
Currently this is being looked up at a number of places. Read and store it
once at bootup so that it can be used by all later.
Signed-off-by: Rajat Jain
---
v2: Commit log cosmetic changes
drivers/pci/p2pdma.c | 2 +-
drivers/pci/pci.c| 21 +
drivers/pci/pci.h| 2
am devices as "untrusted". The
external-facing devices themselves are left as "trusted". This was
discussed here: https://lkml.org/lkml/2020/6/10/1049
Signed-off-by: Rajat Jain
---
v2: cosmetic changes in commit log
drivers/iommu/intel/iommu.c | 2 +-
drivers/pci/of.c|
to clear drivers_autoprobe.
Another problem is that even with drivers_autoprobe=0, the hot-added
PCI devices are bound to drivers because PCI explicitly calls
device_attach() asking driver core to find and attach a driver. This
patch helps with both of these problems.
Signed-off-by: Rajat Jain
rmware info. Any
device not behind the "ExternalFacing" bridges are marked internal and
the ones behind such bridges are markes external.
Signed-off-by: Rajat Jain
---
v2: (Initial version)
drivers/iommu/intel/iommu.c | 31 +--
drivers/pci/ats.c | 2 +-
as an ABI elsewhere, so settled for "site"). Individual buses
that want to support this new attribute can opt-in by setting a flag in
bus_type, and then populating the location of device while enumerating
it.
Signed-off-by: Rajat Jain
---
v2: (Initial version)
drivers/bas
bug.
* 5th and 6th patches expose a device's location into the sysfs to allow
admin to make decision based on that.
* 7th patch is to ensure that the external devices don't bind to drivers
during boot.
Rajat Jain (7):
PCI: Keep the ACS capability offset in device
PCI: Set "untrusted&
led
>
> On Thu, Jun 25, 2020 at 05:27:09PM -0700, Rajat Jain wrote:
> > device_attach() returning failure indicates a driver error
> > while trying to probe the device. In such a scenario, the PCI
> > device should still be added in the system and be visible to
> >
Hello,
Thanks for taking a look.
On Fri, Jun 26, 2020 at 7:18 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Jun 25, 2020 at 05:27:10PM -0700, Rajat Jain wrote:
> > Introduce a PCI parameter that disables the automatic attachment of
> > untrusted devices to their drivers.
> >
lways")
Signed-off-by: Rajat Jain
---
drivers/pci/bus.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 8e40b3e6da77d..3cef835b375fd 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -322,12 +322,8 @@ void pci_bus_add_dev
Introduce a PCI parameter that disables the automatic attachment of
untrusted devices to their drivers.
Signed-off-by: Rajat Jain
---
Context:
I set out to implement the approach outlined in
https://lkml.org/lkml/2020/6/9/1331
https://lkml.org/lkml/2020/6/15/1453
But to my surprise
Hi Ashok,
On Fri, Jun 19, 2020 at 9:10 AM Raj, Ashok wrote:
>
> Hi Rajat
>
>
> On Mon, Jun 15, 2020 at 06:17:41PM -0700, Rajat Jain wrote:
> > When enabling ACS, currently the bit "translation blocking" was
> > not getting changed at all. Set it to disab
Hi Bjorn, All,
Thank you so much for your helpful review and inputs.
On Mon, Jun 15, 2020 at 6:17 PM Rajat Jain wrote:
>
> This is needed to allow the userspace to determine when an untrusted
> device has been added, and thus allowing it to bind the driver manually
> to it, if
Thanks Greg and Andy for your continued inputs, and thanks Ashok for chiming in.
On Thu, Jun 18, 2020 at 9:23 AM Raj, Ashok wrote:
>
> Hi Greg,
>
>
> On Thu, Jun 18, 2020 at 06:02:12PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Jun 18, 2020 at 08:03:49AM -0700, Rajat Ja
Hello,
On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko
wrote:
>
> On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote:
> > > On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote:
> &g
Hi Greg, Christoph,
On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig wrote:
>
> On Tue, Jun 16, 2020 at 12:27:35PM -0700, Rajat Jain wrote:
> > Need clarification. The flag "untrusted" is currently a part of
> > pci_dev struct, and is populated withi
On Tue, Jun 16, 2020 at 12:32 AM Christoph Hellwig wrote:
>
> On Mon, Jun 15, 2020 at 06:17:42PM -0700, Rajat Jain via iommu wrote:
> > This is needed to allow the userspace to determine when an untrusted
> > device has been added, and thus allowing it to bind t
On Wed, Jun 10, 2020 at 12:57 PM Rajat Jain wrote:
>
> On Tue, Jun 9, 2020 at 6:34 PM Oliver O'Halloran wrote:
> >
> > On Wed, Jun 10, 2020 at 7:04 AM Bjorn Helgaas wrote:
> > >
> > > To sketch this out, my understanding of how this would work is:
> >
This is needed to allow the userspace to determine when an untrusted
device has been added, and thus allowing it to bind the driver manually
to it, if it so wishes. This is being done as part of the approach
discussed at https://lkml.org/lkml/2020/6/9/1331
Signed-off-by: Rajat Jain
---
drivers
When enabling ACS, currently the bit "translation blocking" was
not getting changed at all. Set it to disable translation blocking
too for all external facing or untrusted devices. This is OK
because ATS is only allowed on internal devces.
Signed-off-by: Rajat Jain
---
drivers/pci/pci
Currently this is being looked up at a number of places. Read
and store it once at bootup so that it can be used by all later.
Signed-off-by: Rajat Jain
---
drivers/pci/p2pdma.c | 2 +-
drivers/pci/pci.c| 21 +
drivers/pci/pci.h| 2 +-
drivers/pci/probe.c | 2
d then use it to mark any downstream devices as "untrusted". The
external-facing devices themselves are left as "trusted". This was
discussed here: https://lkml.org/lkml/2020/6/10/1049
Signed-off-by: Rajat Jain
---
drivers/iommu/intel/iommu.c | 2 +-
drivers/pci/of.c
On Wed, Jun 10, 2020 at 4:01 PM Bjorn Helgaas wrote:
>
> On Tue, Jun 09, 2020 at 05:30:13PM -0700, Rajat Jain wrote:
> > On Tue, Jun 9, 2020 at 5:04 PM Bjorn Helgaas wrote:
> > > On Tue, Jun 09, 2020 at 04:23:54PM -0700, Rajat Jain wrote:
> > > > Thanks for sen
On Tue, Jun 9, 2020 at 5:30 PM Rajat Jain wrote:
>
> On Tue, Jun 9, 2020 at 5:04 PM Bjorn Helgaas wrote:
> >
> > On Tue, Jun 09, 2020 at 04:23:54PM -0700, Rajat Jain wrote:
> > > Hi Bjorn,
> > >
> > > Thanks for sending out the summary, I
On Tue, Jun 9, 2020 at 6:34 PM Oliver O'Halloran wrote:
>
> On Wed, Jun 10, 2020 at 7:04 AM Bjorn Helgaas wrote:
> >
> > To sketch this out, my understanding of how this would work is:
> >
> > - Expose the PCI pdev->untrusted bit in sysfs. We don't expose this
> > today, but doing so
On Tue, Jun 9, 2020 at 5:04 PM Bjorn Helgaas wrote:
>
> On Tue, Jun 09, 2020 at 04:23:54PM -0700, Rajat Jain wrote:
> > Hi Bjorn,
> >
> > Thanks for sending out the summary, I was about to send it out but got lazy.
> >
> > On Tue, Jun 9, 2020 at 2:04 PM Bjor
Hi Bjorn,
Thanks for sending out the summary, I was about to send it out but got lazy.
On Tue, Jun 9, 2020 at 2:04 PM Bjorn Helgaas wrote:
>
> On Sun, Jun 07, 2020 at 01:36:32PM +0200, Greg Kroah-Hartman wrote:
>
> > Your "problem" I think can be summed up a bit more concise:
> > - you
Hi Jesse and Greg,
On Mon, Jun 8, 2020 at 11:30 AM Jesse Barnes wrote:
>
> > > I think your suggestion to disable driver binding once the initial
> > > bus/slot devices have been bound will probably work for this
> > > situation. I just wanted to be clear that without some auditing,
> > >
Hello Greg,
Thank you for continuing to work with me through this.
On Fri, Jun 5, 2020 at 1:02 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Jun 04, 2020 at 12:38:18PM -0700, Rajat Jain wrote:
> > Hello,
> >
> > I spent some more thoughts into this...
> >
> >
Hello,
I spent some more thoughts into this...
On Wed, Jun 3, 2020 at 5:16 AM Greg Kroah-Hartman
wrote:
>
> On Wed, Jun 03, 2020 at 04:51:18AM -0700, Rajat Jain wrote:
> > Hello,
> >
> > >
> > > > Thanks for the pointer! I'm still looking at th
On Tue, Jun 2, 2020 at 10:30 PM Mika Westerberg
wrote:
>
> On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> > +static bool risky_device(struct pci_dev *pdev)
> > +{
> > + if (pdev->untrusted) {
> > + pci_warn(pdev,
> > +
-by: Rajat Jain
Acked-by: Lu Baolu
Reviewed-by: Ashok Raj
---
v4: - Add Ashok Raj's "Reviewed-by"
- Use pci_info() and split debug print cleanly into 2 statements.
v3: - Separate out the warning mesage in a function to be called from
other places. Change the warning string as
Hi Greg,
Thanks for looking into this thread.
On Wed, Jun 3, 2020 at 5:16 AM Greg Kroah-Hartman
wrote:
>
> On Wed, Jun 03, 2020 at 04:51:18AM -0700, Rajat Jain wrote:
> > Hello,
> >
> > >
> > > > Thanks for the pointer! I'm still looking at th
Hello,
>
> > Thanks for the pointer! I'm still looking at the details yet, but a
> > quick look (usb_dev_authorized()) seems to suggest that this API is
> > "device based". The multiple levels of "authorized" seem to take shape
> > from either how it is wired or from userspace choice. Once
On Mon, Jun 1, 2020 at 10:06 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Jun 01, 2020 at 06:25:42PM -0500, Bjorn Helgaas wrote:
> > [+cc Greg, linux-kernel for wider exposure]
>
> Thanks for the cc:, missed this...
>
> >
> > On Tue, May 26, 2020 at 09:30:08AM -070
On Tue, Jun 2, 2020 at 4:49 PM Prashant Malani wrote:
>
> Hi Rajat,
Hi Prashant, thanks for taking a look.
>
> On Tue, Jun 02, 2020 at 04:26:02PM -0700, Rajat Jain wrote:
> > Currently, an external malicious PCI device can masquerade the VID:PID
> > of faulty gfx devic
-by: Rajat Jain
Acked-by: Lu Baolu
---
v3: - Separate out the warning mesage in a function to be called from
other places. Change the warning string as suggested.
v2: - Change the warning print strings.
- Add Lu Baolu's acknowledgement.
drivers/iommu/intel-iommu.c | 37
Hi MIka,
Thanks for taking a look.
On Tue, Jun 2, 2020 at 2:50 AM Mika Westerberg
wrote:
>
> On Mon, Jun 01, 2020 at 10:45:17PM -0700, Rajat Jain wrote:
> > Currently, an external malicious PCI device can masquerade the VID:PID
> > of faulty gfx devices, and thus
-by: Rajat Jain
Acked-by: Lu Baolu
---
V2: - Change the warning print strings.
- Add Lu Baolu's acknowledgement.
drivers/iommu/intel-iommu.c | 38 +
1 file changed, 38 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
-by: Rajat Jain
---
drivers/iommu/intel-iommu.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index ef0a5246700e5..f2a480168a02f 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
f-band wakeup support")
> > Signed-off-by: Geert Uytterhoeven
> > Acked-by: Rob Herring
>
> If it matters:
>
> Reviewed-by: Brian Norris
Acked-by: Rajat Jain
>
> We're definitely using the plural ("interrupt-names") not the
> singular, so this was just a typo.
>
> Brian
On Sat, Sep 7, 2019 at 10:42 AM Andy Shevchenko
wrote:
>
> On Fri, Aug 23, 2019 at 1:44 AM Rajat Jain wrote:
> >
> > On Thu, Jun 27, 2019 at 8:34 PM Rajat Jain wrote:
> > >
> > > Most modern platforms already have the ACPI device "INT33A1" th
On Tue, Aug 27, 2019 at 3:21 PM Rajat Jain wrote:
>
> The elements in the aer_uncorrectable_error_string[] refer to
> the bit names in Uncorrectable Error status Register in the PCIe spec
> (Sec 7.8.4.2 in PCIe 4.0)
>
> Add the last error bit in the strings array that was missi
The elements in the aer_uncorrectable_error_string[] refer to
the bit names in Uncorrectable Error status Register in the PCIe spec
(Sec 7.8.4.2 in PCIe 4.0)
Add the last error bit in the strings array that was missing.
Signed-off-by: Rajat Jain
---
v3: same as v2
v2: same as v1
drivers/pci
#
Each file is has a single counter value. Single file containing all
stats was frowned upon and discussed here:
https://lkml.org/lkml/2019/6/28/220
Signed-off-by: Rajat Jain
---
v3: indent the sysfs attribute names in documentation.
v2: Also change the Documentation
.../testing/sysfs-bus-pci
The elements in the aer_uncorrectable_error_string[] refer to
the bit names in Uncorrectable Error status Register in the PCIe spec
(Sec 7.8.4.2 in PCIe 4.0)
Add the last error bit in the strings array that was missing.
Signed-off-by: Rajat Jain
---
v2: same as v1
drivers/pci/pcie/aer.c | 3
#
Each file is has a single counter value. Single file containing all
stats was frowned upon and discussed here:
https://lkml.org/lkml/2019/6/28/220
Signed-off-by: Rajat Jain
---
v2: Also change the Documentation
.../testing/sysfs-bus-pci-devices-aer_stats | 160 -
drivers/pci/pcie
On Thu, Jun 27, 2019 at 8:34 PM Rajat Jain wrote:
>
> Most modern platforms already have the ACPI device "INT33A1" that could
> be used to attach to the driver. Switch the driver to using that and
> thus make the intel_pmc_core.c a pure platform_driver.
>
> Some of
The elements in the aer_uncorrectable_error_string[] refer to
the bit names in Uncorrectable Error status Register in the PCIe spec
(Sec 7.8.4.2 in PCIe 4.0)
Add the last error bit in the strings array that was missing.
Signed-off-by: Rajat Jain
---
drivers/pci/pcie/aer.c | 3 ++-
1 file
#
Each file is has a single counter value. Single file containing all
stats was frowned upon and discussed here:
https://lkml.org/lkml/2019/6/28/220
Signed-off-by: Rajat Jain
---
I personally think that this makes it a little overwhelming for a human,
e.g. I could look at total but don't exactly know
Hi Andy,
On Tue, Jun 11, 2019 at 12:06 PM Andy Shevchenko
wrote:
>
> On Thu, May 9, 2019 at 2:15 AM Rajat Jain wrote:
>
> > OK, NP. Just to be sure I understand,
> >
> > 1) Please let me know if I should send in a fix (it would be
> > #include/linux/module.
stem where it should be. This was discussed here:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1966991.html
Signed-off-by: Rajat Jain
---
v7: Include module.h and add MODULE_LICENSE()
v6: was here: https://patchwork.kernel.org/patch/10906387/
(The patchset was accepted, but this particular patch wa
On Fri, Jun 21, 2019 at 7:15 AM Bjorn Helgaas wrote:
>
> On Fri, Jun 21, 2019 at 09:29:11AM +0200, Greg KH wrote:
> > Hi,
> >
> > When working on some documentation scripts to show the
> > Documentation/ABI/ files in an automated way, I ran across this "gem" of
> > a sysfs file:
The lightbar driver never assigned the drvdata in probe method, and
thus there is nothing there. Need to get the ec_dev from the parent's
drvdata.
Signed-off-by: Rajat Jain
---
drivers/platform/chrome/cros_ec_lightbar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi Enric,
On Wed, Jun 26, 2019 at 1:34 PM Enric Balletbo i Serra
wrote:
>
> Hi Rajat,
>
> On 25/6/19 22:51, Rajat Jain wrote:
> > The lightbar driver never assigned the drvdata in probe method, and thus
> > causes a panic when it is accessed at the suspend time.
&g
The lightbar driver never assigned the drvdata in probe method, and thus
causes a panic when it is accessed at the suspend time.
Signed-off-by: Rajat Jain
---
drivers/platform/chrome/cros_ec_lightbar.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/platform
the GPEs for wake enabled devices,
and verified that this fixes the regression I was seeing on multiple of
my devices.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203579
Signed-off-by: Rajat Jain
---
drivers/acpi/sleep.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/acpi/sle
From: Andy Shevchenko
Date: Wed, May 8, 2019 at 2:22 PM
To: Randy Dunlap
Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing
List, Rajat Jain, Platform Driver, Rajneesh Bhardwaj, Vishwanath
Somayaji
> On Wed, May 8, 2019 at 11:45 PM Randy Dunlap wrote:
> >
> > On
On Thu, Apr 11, 2019 at 6:46 AM Andy Shevchenko
wrote:
>
> On Thu, Apr 11, 2019 at 3:38 AM Rajat Jain wrote:
> >
> > Add code to instantiate the pmc_core platform device and thus attach to
> > the driver, if the ACPI device for the same ("INT33A1") is not prese
On Thu, Apr 11, 2019 at 6:40 AM Andy Shevchenko
wrote:
>
> On Thu, Apr 11, 2019 at 3:38 AM Rajat Jain wrote:
> >
> > Add a module parameter which when enabled, will check on resume, if the
> > last S0ix attempt was successful. If not, the driver would warn and p
On Thu, Apr 11, 2019 at 6:44 AM Andy Shevchenko
wrote:
>
> On Thu, Apr 11, 2019 at 3:37 AM Rajat Jain wrote:
> >
> > Convert the intel_pmc_core driver to a platform driver, and attach using
> > the ACPI enumeration method (via the ACPI device "INT33A1").
&g
S0ix failures. Specially since
the latched debug information will be lost (over-written) if the system
attempts to go into runtime (or imminent) S0ix again after that failed
suspend attempt.
Signed-off-by: Rajat Jain
---
v6: Some code restructuring, single conditional per if stmt.
Change from
stem where it should be. This was discussed here:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1966991.html
Signed-off-by: Rajat Jain
---
v6: Squash some of the changes of first patch into this patch to work
around the bisectability issue.
v5: Remove the gerrit id from commit log
v4: Rename file,
Convert the intel_pmc_core driver to a platform driver. There is no
functional change to the driver, or to the way the devices are
instantiated.
Signed-off-by: Rajat Jain
---
v6: Let the way devices are instantiated exactly the same as before this
patch (so no functional change other than
1 - 100 of 625 matches
Mail list logo
