On Tue, Apr 13, 2021 at 11:42:15PM +0530, Vidya Sagar wrote:
> On 4/13/2021 3:23 AM, Bjorn Helgaas wrote:
> > The existing port services (AER, DPC, hotplug, etc) are things the
> > device advertises via the PCI Capabilities defined by the generic PCIe
> > spec, and in my opinion the support for th
On 4/13/2021 11:43 PM, Rob Herring wrote:
External email: Use caution opening links or attachments
On Mon, Apr 12, 2021 at 12:01 PM Vidya Sagar wrote:
Hi
I'm starting this mail to seek advice on the best approach to be taken
to add support for the driver of the PCIe root port's DMA engine
On Mon, Apr 12, 2021 at 12:01 PM Vidya Sagar wrote:
>
> Hi
> I'm starting this mail to seek advice on the best approach to be taken
> to add support for the driver of the PCIe root port's DMA engine.
> To give some background, Tegra194's PCIe IPs are dual-mode PCIe IPs i.e.
> they work either in t
On 4/13/2021 3:23 AM, Bjorn Helgaas wrote:
External email: Use caution opening links or attachments
[+cc Matthew for portdrv comment]
On Mon, Apr 12, 2021 at 10:31:02PM +0530, Vidya Sagar wrote:
Hi
I'm starting this mail to seek advice on the best approach to be taken to
add support for th
[+cc Matthew for portdrv comment]
On Mon, Apr 12, 2021 at 10:31:02PM +0530, Vidya Sagar wrote:
> Hi
> I'm starting this mail to seek advice on the best approach to be taken to
> add support for the driver of the PCIe root port's DMA engine.
> To give some background, Tegra194's PCIe IPs are dual-m
Hi Mauro,
On Wed, Apr 17, 2013 at 07:43:00AM -0300, Mauro Carvalho Chehab wrote:
> and a camera anymore. The OMAP2 were used on some Nokia phones.
> They used to maintain that code, but now that they moved to the dark
> side of the moon, they lost their interests on it. So, it may not
> be easily
On Fri, Apr 19, 2013 at 8:43 AM, Michel Lespinasse wrote:
>
> Just a suggestion: when file->f_op->mmap returns an error code,
> mmap_region() currently has to call unmap_region() to undo any partial
> mappings that might have been created by the device driver. Would it
> make more sense to ask tha
On Tue, Apr 16, 2013 at 8:12 PM, Linus Torvalds
wrote:
> Guys, I just pushed out a new helper function intended for cleaning up
> various device driver mmap functions, because they are rather messy,
> and at least part of the problem was the bad impedance between what a
> driver author would want
On Wed, Apr 17, 2013 at 2:28 PM, Arnd Bergmann wrote:
>
> There is a separate check for the physical address that gets
> mapped in hpet_mmap:
Ahh, right you are. The earlier check for PAGE_SIZE's mapping and zero
offset is indeed superfluous.
Linus
--
To unsubscribe from this list: send
On Wednesday 17 April 2013, Linus Torvalds wrote:
> Not the way things are now.
>
> vm_iomap_memory() actually allows non-page-aligned things to be
> mapped, with the assumption that the user will then know about the
> internal offsets.
>
> The reason for that is questionable, but that's how prett
On Wed, Apr 17, 2013 at 2:15 AM, Arnd Bergmann wrote:
>
> I took a look at the hpet_mmap function, which still contains this check:
>
> if (((vma->vm_end - vma->vm_start) != PAGE_SIZE) || vma->vm_pgoff)
> return -EINVAL;
>
> As far as I can tell, this check is implied by th
On Wed, Apr 17, 2013 at 10:27 AM, David Miller wrote:
>
> Passing PCI BARs into these routines is illegal, we have proper
> abstractions for mmap()'ing PCI resources via pci_mmap_page_range()
> et al.
>
> So, any code doing that needs to be fixed.
Hmm. I've definitely seen code that does that (we
From: Linus Torvalds
Date: Wed, 17 Apr 2013 10:20:43 -0700
> On Wed, Apr 17, 2013 at 10:11 AM, David Miller wrote:
>>
>> Yeah, the only thing special we do on sparc is interpret the PFN
>> specially. We munge it into the real physical address and then
>> pass it all down to remap_pfn_range() to
On Wed, Apr 17, 2013 at 10:11 AM, David Miller wrote:
>
> Yeah, the only thing special we do on sparc is interpret the PFN
> specially. We munge it into the real physical address and then
> pass it all down to remap_pfn_range() to do the real work.
So the main thing I want to check is that *if*
From: Linus Torvalds
Date: Wed, 17 Apr 2013 07:44:33 -0700
> (*) io_remap_pfn_page() is the "extended" version that takes care of
> some special magical details on a couple of odd architectures, notably
> sparc (but also one special case of MIPS PAE that have some magic bit
> tricks). But even fo
On Wed, Apr 17, 2013 at 4:34 AM, Tomi Valkeinen wrote:
>
> Should there be a similar helper that uses remap_pfn_range() instead of
> io_remap_pfn_range()?
The two are practically identical (*). I went back-and-forth over
which one to use, and ended up using io_remap_pfn_range() because that
ends
On 2013-04-17 06:12, Linus Torvalds wrote:
> Guys, I just pushed out a new helper function intended for cleaning up
> various device driver mmap functions, because they are rather messy,
> and at least part of the problem was the bad impedance between what a
> driver author would want to have, and
Em Tue, 16 Apr 2013 20:12:32 -0700
Linus Torvalds escreveu:
> Guys, I just pushed out a new helper function intended for cleaning up
> various device driver mmap functions, because they are rather messy,
> and at least part of the problem was the bad impedance between what a
> driver author would
Arnd Bergmann wrote:
> On Wednesday 17 April 2013, Linus Torvalds wrote:
>> Anyway, I'm attaching the untested patch to several drivers. Guys,
>> mind taking a look?
>
> I took a look at the hpet_mmap function, which still contains this check:
>
> if (((vma->vm_end - vma->vm_start) != PAGE_
On Wednesday 17 April 2013, Linus Torvalds wrote:
> Anyway, I'm attaching the untested patch to several drivers. Guys,
> mind taking a look? The point here is to simplify the interface,
> avoiding bugs, but also:
>
> 5 files changed, 21 insertions(+), 87 deletions(-)
>
> it needs current -git fo
At Tue, 16 Apr 2013 20:12:32 -0700,
Linus Torvalds wrote:
>
> Guys, I just pushed out a new helper function intended for cleaning up
> various device driver mmap functions, because they are rather messy,
> and at least part of the problem was the bad impedance between what a
> driver author would
On 02/06/07, Matt Fredrickson <[EMAIL PROTECTED]> wrote:
- "Daniel J Blueman" <[EMAIL PROTECTED]> wrote:
> On 1 Jun, 19:40, "Lee Revell" <[EMAIL PROTECTED]> wrote:
> > On 6/1/07, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
> >
> > > is it acceptable (although
> > > not nice) to simply fix
- "Arjan van de Ven" <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-06-01 at 12:47 -0500, Matthew Fredrickson wrote:
>
> > My question is this: is there a way to either work around the
> problem I
> > am seeing with the stack without recompiling the kernel with 8K
> stack
> > size or without dis
On 6/3/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Fri, 2007-06-01 at 12:47 -0500, Matthew Fredrickson wrote:
> My question is this: is there a way to either work around the problem I
> am seeing with the stack without recompiling the kernel with 8K stack
> size or without disabling irqs
On Fri, 2007-06-01 at 12:47 -0500, Matthew Fredrickson wrote:
> My question is this: is there a way to either work around the problem I
> am seeing with the stack without recompiling the kernel with 8K stack
> size or without disabling irqs for such a long period of time (which I
> think is not
- "Daniel J Blueman" <[EMAIL PROTECTED]> wrote:
> On 1 Jun, 19:40, "Lee Revell" <[EMAIL PROTECTED]> wrote:
> > On 6/1/07, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
> >
> > > is it acceptable (although
> > > not nice) to simply fix it this way, by disabling irqs while it
> loads
> > > the
Hi Matthew,
On 6/1/07, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
Greetings,
I maintain a device driver that has been bitten by the transition to 4K
stacks. It is a T1/E1 line interface PCI card driver that is
maintained outside of the kernel, although is used by a significant
number of pe
On 1 Jun, 19:40, "Lee Revell" <[EMAIL PROTECTED]> wrote:
On 6/1/07, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
> is it acceptable (although
> not nice) to simply fix it this way, by disabling irqs while it loads
> the firmware?
I would say to just disable IRQs while loading firmware. Almos
Lee Revell wrote:
> On 6/1/07, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
>> is it acceptable (although
>> not nice) to simply fix it this way, by disabling irqs while it loads
>> the firmware?
>>
>
> I would say to just disable IRQs while loading firmware. Almost every
> server I maintain ha
On 6/1/07, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
is it acceptable (although
not nice) to simply fix it this way, by disabling irqs while it loads
the firmware?
I would say to just disable IRQs while loading firmware. Almost every
server I maintain has some vendor driver which generat
jalaja devi wrote:
>
> I want to port a Network driver from kernel2.2.x to
> 2.4. Could anyone please point me a handy pointer
> where i can find a complete documentation.
http://www.firstfloor.org/~andi/softnet/
Also, take a look at acenic.c and eepro100.c. They
both support 2.2 and 2.4. The
Friedrich Steven E CONT CNIN wrote:
> If you want to mmap the device then you really want to put the
> device in its own 4K aligned 4K sized PCI window, otherwise adjacent
> devices will become accessible too and that might not be desirable.
If you can, reprogram the device's PCI configurat
a couple questions below...
-Original Message-
From: Alan Cox
Sent: Friday, April 13, 2001 14:47
To: Friedrich Steven E CONT CNIN
Cc: [EMAIL PROTECTED]
Subject:Re: device driver questions
> My device shows
> My device shows up in /proc/iomem even before I load my device driver,
> indicating that the pci subsystem mapped it into the kernel pages. But bar0
Actually the addresses you see there are physical bus addresses not neccessarily
and on x86 quite likely not actually mapped.
> Why didn't the p
> but the point is that though most cards hold firmware on a PROM, a few
> hold the firmware in the driver.
>
> firmware in PROM, firmware in driver... what's the difference?
I like to know what I get. One reason to disable modules on servers
here. Only reason I use them here is a Bug 'n Pray S
>
>
> > I take it then that you never use a hard drive in any of your systems on
> > the grounds that it contains non-open source firmware which may affect
> > the security of your system? ;) Tell me, what do you use to store all
> > those Linux applications on?
>
> Your ATA drive can't tell y
Igmar Palsenberg <[EMAIL PROTECTED]> SAID:
> > I take it then that you never use a hard drive in any of your systems on
> > the grounds that it contains non-open source firmware which may affect
> > the security of your system? ;) Tell me, what do you use to store all
> > those Linux application
> For my own system : I don't care. But I can imagine that there are people
> out there that do care about these kind of issues.
>
but the point is that though most cards hold firmware on a PROM, a few
hold the firmware in the driver.
firmware in PROM, firmware in driver... what's the differen
> I wrote the SmartMedia FlashPath driver, and I can
> say that the SmartMedia is fine, but the FlashPath is a
> little silly. (And I sometimes feel very bad for what
> I was forced to write due to NDA and time constraints)..
A lot of the NDA's on smart media are the smart media peoples pr
> I take it then that you never use a hard drive in any of your systems on
> the grounds that it contains non-open source firmware which may affect
> the security of your system? ;) Tell me, what do you use to store all
> those Linux applications on?
Your ATA drive can't tell you kernel what to
H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Ok, yes now I get it. Yes, this is stupid.
> Anyone here have any experience with SmartMedia and if they are sane or
> stupid?
I wrote the SmartMedia FlashPath driver, and I can
say that the SmartMedia is fine, but the FlashPath is a
little s
Igmar Palsenberg writes:
> In the last case, you load something direct into kernel space. In case of
> binary stuff you have no idea what actually happens. Also the case with
> the before boot issue, but this plays a bigger role.
I take it then that you never use a hard drive in any of your syste
> Quite a few. You can make the driver upload be done via a userspace app so its
> pretty clearly seperate from the kernel.
>
> As to the security risk - yes if you run a military installation or something
> that is similarly paranoid. However its no different to the firmware burned into
> ROM o
> >Every closed source piece of software is unacceptable in a standard kernel
> >:
> >
> >-hh We can't debug it
> >- We depend on the guys / girls that maintain the binary image
> >- It's a security risk.
> >
> Aren't there other examples where firmware is supplied in a struct
> which is initiali
Andre Hedrick wrote:
> >
> > I don't understand why you say this... CompactFlash, for example, is a
> > solid-state HDD device, and it speaks ATA just as well as any disk.
> > No special binaries required.
>
> This is my point.
>
> www.platypustechnology.com SSD/HDD's require a firmware load to
On Mon, 16 Oct 2000, John Alvord wrote:
> On Mon, 16 Oct 2000 14:45:03 +0200 (CEST), Igmar Palsenberg
> <[EMAIL PROTECTED]> wrote:
>
> >
> >> >I presume your driver doesn't mind if this image is unavailable.
> >> >If not, you'll need to provide a open source image to use in place
> >> >of your
> Aren't there other examples where firmware is supplied in a struct
> which is initialized to the needed binary values? Seems like Linux
> doesn't need every bit of source (probably for some completely other
> processor or ASIC, maybe written in FORTH) included as part of the
> kernel.
Quite a f
> See Documentation/SubmittingDrivers in a current kernel. (I've mailed you a
Speaking of that file,
< Portability:Pointers are not always 32bits, people do not all have
< floating point and you shouldn't use inline x86 assembler in
< your driver without caref
On Mon, 16 Oct 2000 14:45:03 +0200 (CEST), Igmar Palsenberg
<[EMAIL PROTECTED]> wrote:
>
>> >I presume your driver doesn't mind if this image is unavailable.
>> >If not, you'll need to provide a open source image to use in place
>> >of your proprietary one.
>>
>> Linus, please confirm.
>>
>> F
> >I presume your driver doesn't mind if this image is unavailable.
> >If not, you'll need to provide a open source image to use in place
> >of your proprietary one.
>
> Linus, please confirm.
>
> Firmware for cards can be proprietary. It can either be installed by a
> userspace utility on st
> how do we begin the process of getting our drivers included into the =
> kernel?
>
See Documentation/SubmittingDrivers in a current kernel. (I've mailed you a
copy of the file offlist)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
Keith Owens wrote:
> On Sun, 15 Oct 2000 09:57:08 -0700,
> Miles Lane <[EMAIL PROTECTED]> wrote:
> >> On Mon, 16 Oct 2000 14:30:39 +1000,
> >> "Mike McLeod" <[EMAIL PROTECTED]> wrote:
> >> >All of the code is open except for an image file that is loaded
> >> >onto the card when the driver is ins
On 15 Oct 2000, H. Peter Anvin wrote:
> > Nobody asked but, HDD solid state devices that could be used for booting
> > would require the linking or inclusion of of non-open binaries that must
> > be executed once the release of INT13/INT19 are completed from the bios
> > bootstrapping. We are lo
Followup to: <[EMAIL PROTECTED]>
By author:Andre Hedrick <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Nobody asked but, HDD solid state devices that could be used for booting
> would require the linking or inclusion of of non-open binaries that must
> be executed once the release o
On Mon, 16 Oct 2000, Keith Owens wrote:
> On Sun, 15 Oct 2000 09:57:08 -0700,
> Miles Lane <[EMAIL PROTECTED]> wrote:
> >> On Mon, 16 Oct 2000 14:30:39 +1000,
> >> "Mike McLeod" <[EMAIL PROTECTED]> wrote:
> >> >All of the code is open except for an image file that is loaded
> >> >onto the card
Thanks, all, for the education.
Sounds like I got this wrong.
Miles
Keith Owens wrote:
>
> On Sun, 15 Oct 2000 09:57:08 -0700,
> Miles Lane <[EMAIL PROTECTED]> wrote:
> >> On Mon, 16 Oct 2000 14:30:39 +1000,
> >> "Mike McLeod" <[EMAIL PROTECTED]> wrote:
> >> >All of the code is open exc
On Sun, 15 Oct 2000 09:57:08 -0700,
Miles Lane <[EMAIL PROTECTED]> wrote:
>> On Mon, 16 Oct 2000 14:30:39 +1000,
>> "Mike McLeod" <[EMAIL PROTECTED]> wrote:
>> >All of the code is open except for an image file that is loaded
>> >onto the card when the driver is installed that handles it's
>> >l
> On Mon, 16 Oct 2000 14:30:39 +1000,
> "Mike McLeod" <[EMAIL PROTECTED]> wrote:
> >All of the code is open except for an image file that is loaded
> >onto the card when the driver is installed that handles it's
> >logic. From here, how do we begin the process of getting our
> >drivers includ
-
From: "Keith Owens" <[EMAIL PROTECTED]>
To: "Mike McLeod" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, October 16, 2000 1:57 PM
Subject: Re: Device Driver
> On Mon, 16 Oct 2000 14:30:39 +1000,
> "Mike McLeod" <[EMAIL PR
On Mon, 16 Oct 2000 14:30:39 +1000,
"Mike McLeod" <[EMAIL PROTECTED]> wrote:
>The company I work for has developed a new piece of hardware, and we are
>eager to have the drivers for this hardware included as part of the
>Linux kernel. Currently, we have customers who have been using our
>product
> I have a trivial question, is it possible to Open a Device Driver (A)
> within and other Device Driver (B) and Handle the driver-A similar to how
> an application uses the Driver.
It is certainly possible to call the same operations, yes, if done with
proper care. One example you could look
61 matches
Mail list logo
