Quoting Stephen Boyd (2018-08-09 19:54:27)
> What's with the top posting? ;-)
>
> Quoting Julius Werner (2018-08-09 16:44:43)
> > Actually, looking at what IO_STRICT_DEVMEM really does, would it
> > really prevent userspace accesses to these areas? Because it seems
> > that it only prevents
Quoting Stephen Boyd (2018-08-09 19:54:27)
> What's with the top posting? ;-)
>
> Quoting Julius Werner (2018-08-09 16:44:43)
> > Actually, looking at what IO_STRICT_DEVMEM really does, would it
> > really prevent userspace accesses to these areas? Because it seems
> > that it only prevents
What's with the top posting? ;-)
Quoting Julius Werner (2018-08-09 16:44:43)
> Actually, looking at what IO_STRICT_DEVMEM really does, would it
> really prevent userspace accesses to these areas? Because it seems
> that it only prevents accesses to areas marked as IORESOURCE_BUSY, and
> while I
What's with the top posting? ;-)
Quoting Julius Werner (2018-08-09 16:44:43)
> Actually, looking at what IO_STRICT_DEVMEM really does, would it
> really prevent userspace accesses to these areas? Because it seems
> that it only prevents accesses to areas marked as IORESOURCE_BUSY, and
> while I
Actually, looking at what IO_STRICT_DEVMEM really does, would it
really prevent userspace accesses to these areas? Because it seems
that it only prevents accesses to areas marked as IORESOURCE_BUSY, and
while I can't fully follow how the kernel assigns that, comments
suggest that this is only set
Actually, looking at what IO_STRICT_DEVMEM really does, would it
really prevent userspace accesses to these areas? Because it seems
that it only prevents accesses to areas marked as IORESOURCE_BUSY, and
while I can't fully follow how the kernel assigns that, comments
suggest that this is only set
> Furthermore, I see that my system RAM excludes this coreboot table so it
> doesn't fall into the bucket that CONFIG_STRICT_DEVMEM would find.
Yes, that is intentional. We don't want the kernel to try to use that
memory for anything else (since we want those tables to survive), so
we mark them
> Furthermore, I see that my system RAM excludes this coreboot table so it
> doesn't fall into the bucket that CONFIG_STRICT_DEVMEM would find.
Yes, that is intentional. We don't want the kernel to try to use that
memory for anything else (since we want those tables to survive), so
we mark them
Quoting Julius Werner (2018-08-09 14:07:31)
> On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd wrote:
> >
> > Call request_mem_region() on the entire coreboot table to make sure
> > other devices don't attempt to map the coreboot table in their drivers.
> > If drivers need that support, it would be
Quoting Julius Werner (2018-08-09 14:07:31)
> On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd wrote:
> >
> > Call request_mem_region() on the entire coreboot table to make sure
> > other devices don't attempt to map the coreboot table in their drivers.
> > If drivers need that support, it would be
On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd wrote:
>
> Call request_mem_region() on the entire coreboot table to make sure
> other devices don't attempt to map the coreboot table in their drivers.
> If drivers need that support, it would be better to provide bus APIs
> they can use to do that
On Thu, Aug 9, 2018 at 10:17 AM Stephen Boyd wrote:
>
> Call request_mem_region() on the entire coreboot table to make sure
> other devices don't attempt to map the coreboot table in their drivers.
> If drivers need that support, it would be better to provide bus APIs
> they can use to do that
Call request_mem_region() on the entire coreboot table to make sure
other devices don't attempt to map the coreboot table in their drivers.
If drivers need that support, it would be better to provide bus APIs
they can use to do that through the mapping created in this file.
Cc: Wei-Ning Huang
Call request_mem_region() on the entire coreboot table to make sure
other devices don't attempt to map the coreboot table in their drivers.
If drivers need that support, it would be better to provide bus APIs
they can use to do that through the mapping created in this file.
Cc: Wei-Ning Huang
14 matches
Mail list logo
