From: Vidya Sagar
[ Upstream commit 3482a7afb261e2de9269a7f9ad0f4a3a82a83a53 ]
Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly
represent 64-bit resources.
Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to
Tegra194 DT")
Signed-off
From: Vidya Sagar
[ Upstream commit 3482a7afb261e2de9269a7f9ad0f4a3a82a83a53 ]
Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly
represent 64-bit resources.
Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to
Tegra194 DT")
Signed-off
From: Vidya Sagar
[ Upstream commit 3482a7afb261e2de9269a7f9ad0f4a3a82a83a53 ]
Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly
represent 64-bit resources.
Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to
Tegra194 DT")
Signed-off
From: Vidya Sagar
[ Upstream commit 3482a7afb261e2de9269a7f9ad0f4a3a82a83a53 ]
Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly
represent 64-bit resources.
Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to
Tegra194 DT")
Signed-off
On Mon, May 18, 2020 at 07:52:24PM +0530, Vidya Sagar wrote:
> Thanks Lorenzo.
> I've moved linux-pci to BCC and included
> devicetree and linux-tegra mailing lists to CC.
>
> Rob, Could you please review this patch?
I don't think there's any need for Rob to review this. It's a simple
bugfix and
at 07:24:37PM +0530, Vidya Sagar wrote:
Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly
represent 64-bit resources.
Signed-off-by: Vidya Sagar
---
V2:
* Extended the change to cover other controllers as well
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 12
On Thu, May 14, 2020 at 07:24:37PM +0530, Vidya Sagar wrote:
> Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly
> represent 64-bit resources.
>
> Signed-off-by: Vidya Sagar
> ---
> V2:
> * Extended the change to cover other controllers as well
Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly
represent 64-bit resources.
Signed-off-by: Vidya Sagar
---
V2:
* Extended the change to cover other controllers as well
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6
Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly
represent 64-bit resources.
Signed-off-by: Vidya Sagar
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b
is checked before making the call.
So if the pbus_size_mem() call in question fails, the window must already
be assigned, and in this case, the code should not try to assign
64-bit resources into the 32-bit catch-all window.
Thus, the fix for the bug is to ensure mask, type2 and type3 are set in
cases
is checked before making the call.
So if the pbus_size_mem() call in question fails, the window must already
be assigned, and in this case, the code should not try to assign
64-bit resources into the 32-bit catch-all window.
Thus, the fix for the bug is to ensure mask, type2 and type3 are set in
cases
Hey Bjorn,
On 2019-03-04 1:11 p.m., Bjorn Helgaas wrote:
> On Mon, Mar 4, 2019 at 1:21 PM Logan Gunthorpe wrote:
>> On 2019-03-03 5:23 p.m., Bjorn Helgaas wrote:
>>> Sorry for the delay. This code gives a headache. I still remember
>>> my headache from the last time we touched it. Help me
On 2019-03-04 12:21 p.m., Logan Gunthorpe wrote:
> The system we hit this bug on is quite large and complex with multiple
> layers of switches though I suspect I might have seen it on a completely
> different system but never had time to dig into it. I guess I could try
> to find a case in
On 2019-03-04 1:29 p.m., Bjorn Helgaas wrote:
>> I agree, but reworking this code scares me and I suspect it was designed
>> this way for a reason. I'm guessing there are a lot of corner cases and
>> unusual bios issues this stuff works around. We might end up fixing a
>> some cases and
On Mon, Mar 4, 2019 at 2:21 PM Logan Gunthorpe wrote:
> On 2019-03-04 1:11 p.m., Bjorn Helgaas wrote:
> > On Mon, Mar 4, 2019 at 1:21 PM Logan Gunthorpe wrote:
> >> On 2019-03-03 5:23 p.m., Bjorn Helgaas wrote:
> >>> Sorry for the delay. This code gives a headache. I still remember
> >>> my
On 2019-03-04 1:11 p.m., Bjorn Helgaas wrote:
> On Mon, Mar 4, 2019 at 1:21 PM Logan Gunthorpe wrote:
>> On 2019-03-03 5:23 p.m., Bjorn Helgaas wrote:
>>> Sorry for the delay. This code gives a headache. I still remember
>>> my headache from the last time we touched it. Help me understand
On Mon, Mar 4, 2019 at 1:21 PM Logan Gunthorpe wrote:
> On 2019-03-03 5:23 p.m., Bjorn Helgaas wrote:
> > Sorry for the delay. This code gives a headache. I still remember
> > my headache from the last time we touched it. Help me understand
> > what's going on here.
>
> Yes, this code gave me
ause, in __pci_bus_size_bridges(), it's
>> existence is checked before making the call. So if the pbus_size_mem()
>> call in question fails, the window must already be assigned, and in this
>> case, we still do not want 64-bit resources trying to be sized into the
>> 32-bit catc
cked before making the call. So if the pbus_size_mem()
> call in question fails, the window must already be assigned, and in this
> case, we still do not want 64-bit resources trying to be sized into the
> 32-bit catch-all resource.
I guess this question of putting a 64-bit resource in th
64-bit resources trying to be sized into the
32-bit catch-all resource.
So to fix the bug, we must always set mask, type2 and type3 in cases
where a 64-bit resource exists even if pbus_size_mem() fails.
Reported-by: Kit Chow
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge window
This adds appropriate casts to avoid a warning and print the correct
values in pr_debug.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/pci/setup-res.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: linux-work/drivers/pci/setup-res.c
This adds appropriate casts to avoid a warning and print the correct
values in pr_debug.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/pci/setup-res.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: linux-work/drivers/pci/setup-res.c
to pte_t and provide accessor macros to
> ensure proper use?
>
> Andrew has also asked me to post size comparisons of
> drivers/*/*.o
> building allmodconfig with 32-bit resources and
> 64-bit resources to
> see what the size growth is. I'll post logs for
> people to tak
core supports up to 36-bit addressing and
they have several CPUs based on this that are already out or will
be released in the next year. I can currently get around 64-bit
resources by playing ugly tricks with the memory map and trapping
ioremap() calls to a certain unused 32-bit physical range and fi
this an arch option and wrap start and end in a typedef
similar to pte_t and provide accessor macros to ensure proper use?
Andrew has also asked me to post size comparisons of drivers/*/*.o
building allmodconfig with 32-bit resources and 64-bit resources to
see what the size growth is. I'll
this an arch option and wrap start and end in a typedef
similar to pte_t and provide accessor macros to ensure proper use?
Andrew has also asked me to post size comparisons of drivers/*/*.o
building allmodconfig with 32-bit resources and 64-bit resources to
see what the size growth is. I'll
and
they have several CPUs based on this that are already out or will
be released in the next year. I can currently get around 64-bit
resources by playing ugly tricks with the memory map and trapping
ioremap() calls to a certain unused 32-bit physical range and fixing
it up to 64-bit (like PPC440
and
64-bit resources to
see what the size growth is. I'll post logs for
people to take a
look at in a followup email.
- Kumar
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
On Mar 10 2005, at 12:09, Kumar Gala was caught saying:
>
> On Mar 10, 2005, at 11:35 AM, Greg KH wrote:
>
> >On Thu, Mar 10, 2005 at 01:46:10AM -0600, Kumar Gala wrote:
> > > Greg,
> > >
> >> I was wondering what the state of the change to 64-bi
On Mar 10 2005, at 12:09, Kumar Gala was caught saying:
On Mar 10, 2005, at 11:35 AM, Greg KH wrote:
On Thu, Mar 10, 2005 at 01:46:10AM -0600, Kumar Gala wrote:
Greg,
I was wondering what the state of the change to 64-bit resources was?
On hold till I get the time to fix all
On Mar 10, 2005, at 11:35 AM, Greg KH wrote:
On Thu, Mar 10, 2005 at 01:46:10AM -0600, Kumar Gala wrote:
> Greg,
>
> I was wondering what the state of the change to 64-bit resources was?
On hold till I get the time to fix all of the kernel tree up due to the
changes required.
Unles
On Thu, Mar 10, 2005 at 01:46:10AM -0600, Kumar Gala wrote:
> Greg,
>
> I was wondering what the state of the change to 64-bit resources was?
On hold till I get the time to fix all of the kernel tree up due to the
changes required.
Unless someone else wants to volunteer to do
On Thu, Mar 10, 2005 at 01:46:10AM -0600, Kumar Gala wrote:
Greg,
I was wondering what the state of the change to 64-bit resources was?
On hold till I get the time to fix all of the kernel tree up due to the
changes required.
Unless someone else wants to volunteer to do the work :)
thanks
On Mar 10, 2005, at 11:35 AM, Greg KH wrote:
On Thu, Mar 10, 2005 at 01:46:10AM -0600, Kumar Gala wrote:
Greg,
I was wondering what the state of the change to 64-bit resources was?
On hold till I get the time to fix all of the kernel tree up due to the
changes required.
Unless someone else
Greg,
I was wondering what the state of the change to 64-bit resources was?
thanks
- kumar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please re
Greg,
I was wondering what the state of the change to 64-bit resources was?
thanks
- kumar
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
36 matches
Mail list logo
