On Thu, Dec 31, 2015 at 9:11 PM, Alex Williamson
wrote:
> On Thu, 2015-12-31 at 15:03 +0530, Santosh Shukla wrote:
>> On Tue, Dec 29, 2015 at 11:01 PM, Alex Williamson
>> wrote:
>> > On Tue, 2015-12-29 at 22:00 +0530, Santosh Shukla wrote:
>> > > On Tue, Dec 29, 2015 at 9:50 PM, Arnd Bergmann
>>
On Thu, 2015-12-31 at 15:03 +0530, Santosh Shukla wrote:
> On Tue, Dec 29, 2015 at 11:01 PM, Alex Williamson
> wrote:
> > On Tue, 2015-12-29 at 22:00 +0530, Santosh Shukla wrote:
> > > On Tue, Dec 29, 2015 at 9:50 PM, Arnd Bergmann
> > > wrote:
> > > > On Tuesday 29 December 2015 21:25:15 Santosh
On Tue, Dec 29, 2015 at 11:01 PM, Alex Williamson
wrote:
> On Tue, 2015-12-29 at 22:00 +0530, Santosh Shukla wrote:
>> On Tue, Dec 29, 2015 at 9:50 PM, Arnd Bergmann wrote:
>> > On Tuesday 29 December 2015 21:25:15 Santosh Shukla wrote:
>> > > mistakenly added wrong email-id of alex, looping his
On Tue, 2015-12-29 at 22:00 +0530, Santosh Shukla wrote:
> On Tue, Dec 29, 2015 at 9:50 PM, Arnd Bergmann wrote:
> > On Tuesday 29 December 2015 21:25:15 Santosh Shukla wrote:
> > > mistakenly added wrong email-id of alex, looping his correct one.
> > >
> > > On 29 December 2015 at 21:23, Santosh
On Tue, Dec 29, 2015 at 9:50 PM, Arnd Bergmann wrote:
> On Tuesday 29 December 2015 21:25:15 Santosh Shukla wrote:
>> mistakenly added wrong email-id of alex, looping his correct one.
>>
>> On 29 December 2015 at 21:23, Santosh Shukla
>> wrote:
>> > On 29 December 2015 at 18:58, Arnd Bergmann w
On Tuesday 29 December 2015 21:25:15 Santosh Shukla wrote:
> mistakenly added wrong email-id of alex, looping his correct one.
>
> On 29 December 2015 at 21:23, Santosh Shukla
> wrote:
> > On 29 December 2015 at 18:58, Arnd Bergmann wrote:
> >> On Wednesday 23 December 2015 17:04:40 Santosh Shu
mistakenly added wrong email-id of alex, looping his correct one.
On 29 December 2015 at 21:23, Santosh Shukla wrote:
> On 29 December 2015 at 18:58, Arnd Bergmann wrote:
>> On Wednesday 23 December 2015 17:04:40 Santosh Shukla wrote:
>>> On 23 December 2015 at 03:26, Arnd Bergmann wrote:
>>> >
On 29 December 2015 at 18:58, Arnd Bergmann wrote:
> On Wednesday 23 December 2015 17:04:40 Santosh Shukla wrote:
>> On 23 December 2015 at 03:26, Arnd Bergmann wrote:
>> > On Tuesday 22 December 2015, Santosh Shukla wrote:
>> >> }
>> >>
>> >> So I care for /dev/ioport types interface who could d
On Wednesday 23 December 2015 17:04:40 Santosh Shukla wrote:
> On 23 December 2015 at 03:26, Arnd Bergmann wrote:
> > On Tuesday 22 December 2015, Santosh Shukla wrote:
> >> }
> >>
> >> So I care for /dev/ioport types interface who could do more than byte
> >> data copy to/from user-space. I teste
On 23 December 2015 at 03:26, Arnd Bergmann wrote:
> On Tuesday 22 December 2015, Santosh Shukla wrote:
>> }
>>
>> So I care for /dev/ioport types interface who could do more than byte
>> data copy to/from user-space. I tested this patch with little
>> modification and could able to run pmd driver
On Tuesday 22 December 2015, H. Peter Anvin wrote:
> On that subject, shouldn't we have common infrastructure to deal with memory
> mapped I/O ports in the kernel? Or do we have that now? I obviously don't
> pay too much attention...
We don't have it at the moment, though some of the code that w
On December 22, 2015 1:56:20 PM PST, Arnd Bergmann wrote:
>On Tuesday 22 December 2015, Santosh Shukla wrote:
>> }
>>
>> So I care for /dev/ioport types interface who could do more than byte
>> data copy to/from user-space. I tested this patch with little
>> modification and could able to run pmd
On Tuesday 22 December 2015, Santosh Shukla wrote:
> }
>
> So I care for /dev/ioport types interface who could do more than byte
> data copy to/from user-space. I tested this patch with little
> modification and could able to run pmd driver for arm/arm64 case.
>
> Like to know how to address pci_
On 30 May 2014 at 17:02, Arnd Bergmann wrote:
> On Thursday 29 May 2014 06:38:35 H. Peter Anvin wrote:
>> On 05/29/2014 02:26 AM, Arnd Bergmann wrote:
>> > On Wednesday 28 May 2014 14:41:52 H. Peter Anvin wrote:
>> >> On 05/19/2014 05:36 AM, Arnd Bergmann wrote:
>> >>>
>> >>> My feeling is that al
On Wed, 4 Jun 2014, H. Peter Anvin wrote:
> > Also IIRC PCI-PCI bridges only forward port I/O space accesses
> > within the low 64kB.
>
> Not true.
It must have been an implementation-specific constraint then (e.g.
DECchip 21050), it's been a while since I looked into it. Thanks for
straigh
On 06/01/2014 03:35 AM, Maciej W. Rozycki wrote:
> Also IIRC PCI-PCI bridges only forward port I/O space accesses
> within the low 64kB.
Not true.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More m
On Sun, 11 May 2014, Josh Triplett wrote:
> > > > What if I attempt a four-byte read at 65535? That would access four
> > > > out-of-bounds bytes, right?
> > >
> > > No, it would do an ind instruction on port 65535.
> >
> > Yes, on x86. What about other architectures?
>
> That's a good point; o
On Thursday 29 May 2014 06:38:35 H. Peter Anvin wrote:
> On 05/29/2014 02:26 AM, Arnd Bergmann wrote:
> > On Wednesday 28 May 2014 14:41:52 H. Peter Anvin wrote:
> >> On 05/19/2014 05:36 AM, Arnd Bergmann wrote:
> >>>
> >>> My feeling is that all devices we can think of fall into at least one
> >>>
On 05/29/2014 02:26 AM, Arnd Bergmann wrote:
> On Wednesday 28 May 2014 14:41:52 H. Peter Anvin wrote:
>> On 05/19/2014 05:36 AM, Arnd Bergmann wrote:
>>>
>>> My feeling is that all devices we can think of fall into at least one
>>> of these categories:
>>>
>>> * legacy PC stuff that needs only byt
On Wednesday 28 May 2014 14:41:52 H. Peter Anvin wrote:
> On 05/19/2014 05:36 AM, Arnd Bergmann wrote:
> >
> > My feeling is that all devices we can think of fall into at least one
> > of these categories:
> >
> > * legacy PC stuff that needs only byte access
> > * PCI devices that can be accesse
On 05/19/2014 05:36 AM, Arnd Bergmann wrote:
>
> My feeling is that all devices we can think of fall into at least one
> of these categories:
>
> * legacy PC stuff that needs only byte access
> * PCI devices that can be accessed through sysfs
> * devices on x86 that can be accessed using iopl
>
On Thursday 15 May 2014 14:56:46 j...@joshtriplett.org wrote:
> On Tue, May 13, 2014 at 03:10:59PM -0700, H. Peter Anvin wrote:
> > On 05/09/2014 03:38 PM, Josh Triplett wrote:
> > > On Fri, May 09, 2014 at 02:20:45PM -0700, H. Peter Anvin wrote:
> > >> On 05/09/2014 02:12 PM, Arnd Bergmann wrote:
On Tue, May 13, 2014 at 03:10:59PM -0700, H. Peter Anvin wrote:
> On 05/09/2014 03:38 PM, Josh Triplett wrote:
> > On Fri, May 09, 2014 at 02:20:45PM -0700, H. Peter Anvin wrote:
> >> On 05/09/2014 02:12 PM, Arnd Bergmann wrote:
> >>>
> However, if we're going to have these devices I'm wonderi
On 05/09/2014 03:38 PM, Josh Triplett wrote:
> On Fri, May 09, 2014 at 02:20:45PM -0700, H. Peter Anvin wrote:
>> On 05/09/2014 02:12 PM, Arnd Bergmann wrote:
>>>
However, if we're going to have these devices I'm wondering if having
/dev/portw and /dev/portl (or something like that) might
On Sun, May 11, 2014 at 02:50:06PM +0200, Jann Horn wrote:
> On Sat, May 10, 2014 at 12:32:46PM -0700, Josh Triplett wrote:
> > On Sat, May 10, 2014 at 09:07:42AM +0200, Jann Horn wrote:
> > > On Fri, May 09, 2014 at 12:19:16PM -0700, Josh Triplett wrote:
> > > > + if (port > 65535)
> > > > +
On Sat, May 10, 2014 at 12:32:46PM -0700, Josh Triplett wrote:
> On Sat, May 10, 2014 at 09:07:42AM +0200, Jann Horn wrote:
> > On Fri, May 09, 2014 at 12:19:16PM -0700, Josh Triplett wrote:
> > > + if (port > 65535)
> > > + return 0;
> > > + switch (count) {
> > [...]
> > > + case 4:
> > >
On Sat, May 10, 2014 at 07:18:45PM +0200, Greg Kroah-Hartman wrote:
> On Fri, May 09, 2014 at 12:19:16PM -0700, Josh Triplett wrote:
> > @@ -827,6 +898,9 @@ static const struct memdev {
> > #ifdef CONFIG_PRINTK
> > [11] = { "kmsg", 0644, &kmsg_fops, NULL },
> > #endif
> > +#ifdef CONFIG_DEVPO
On Sat, May 10, 2014 at 09:07:42AM +0200, Jann Horn wrote:
> On Fri, May 09, 2014 at 12:19:16PM -0700, Josh Triplett wrote:
> > + if (port > 65535)
> > + return 0;
> > + switch (count) {
> [...]
> > + case 4:
> > + if (__put_user(inl(port), buf) < 0)
> > +
On Fri, May 09, 2014 at 12:19:16PM -0700, Josh Triplett wrote:
> @@ -827,6 +898,9 @@ static const struct memdev {
> #ifdef CONFIG_PRINTK
> [11] = { "kmsg", 0644, &kmsg_fops, NULL },
> #endif
> +#ifdef CONFIG_DEVPORT
> + [12] = { "ioports", 0, &ioports_fops, NULL },
Odd extra space?
-
On Fri, May 09, 2014 at 12:19:16PM -0700, Josh Triplett wrote:
> + if (port > 65535)
> + return 0;
> + switch (count) {
[...]
> + case 4:
> + if (__put_user(inl(port), buf) < 0)
> + return -EFAULT;
What if I attempt a four-byte read at 65535?
On Fri, May 09, 2014 at 02:20:45PM -0700, H. Peter Anvin wrote:
> On 05/09/2014 02:12 PM, Arnd Bergmann wrote:
> >
> >> However, if we're going to have these devices I'm wondering if having
> >> /dev/portw and /dev/portl (or something like that) might not make sense,
> >> rather than requiring a s
On 05/09/2014 02:12 PM, Arnd Bergmann wrote:
>
>> However, if we're going to have these devices I'm wondering if having
>> /dev/portw and /dev/portl (or something like that) might not make sense,
>> rather than requiring a system call per transaction.
>
> Actually the behavior of /dev/port for >1
On Friday 09 May 2014 13:54:05 H. Peter Anvin wrote:
> On 05/09/2014 12:58 PM, Arnd Bergmann wrote:
> > On Friday 09 May 2014 12:19:16 Josh Triplett wrote:
> >
> >> +if (!access_ok(VERIFY_WRITE, buf, count))
> >> +return -EFAULT;
> >> +if (port > 65535)
> >> +return
On 05/09/2014 12:58 PM, Arnd Bergmann wrote:
> On Friday 09 May 2014 12:19:16 Josh Triplett wrote:
>
>> +if (!access_ok(VERIFY_WRITE, buf, count))
>> +return -EFAULT;
>> +if (port > 65535)
>> +return 0;
>
> This should probably test against IO_SPACE_LIMIT, which ma
On Friday 09 May 2014 12:19:16 Josh Triplett wrote:
> + if (!access_ok(VERIFY_WRITE, buf, count))
> + return -EFAULT;
> + if (port > 65535)
> + return 0;
This should probably test against IO_SPACE_LIMIT, which may be zero,
something larger than 65536 or even ULONG_
/dev/port only supports reading and writing 8-bit ports; multi-byte
operations on /dev/port will just operate on multiple successive 8-bit
ports.
Add a new device, /dev/ioports, which supports reading and writing
16-bit and 32-bit ports. This makes it possible to perform arbitrary
I/O port operat
36 matches
Mail list logo
