On Fri, 7 Jun 2024 19:55:49 +0200
Danilo Krummrich wrote:
> On Fri, Jun 07, 2024 at 05:41:11PM +0200, Greg KH wrote:
>> On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote:
>> > On Fri, Jun 07, 2024 at 02:36:50PM +0200, Greg KH wrote:
>> > > Anyway, that's all hand-wavy right now, so
tractions of firmware API;
that is, wrapping C's pointer to a device object with Rust struct only
during a caller knows the pointer is valid (e.g., the probe callback).
Co-developed-by: Wedson Almeida Filho
Signed-off-by: Wedson Almeida Filho
Signed-off-by: Danilo Krummrich
Co-developed-by
On Thu, 30 May 2024 08:47:25 +0200
Danilo Krummrich wrote:
>> >> >> For a Rust PHY driver, you know that you have a valid pointer to C's
>> >> >> device object of C's PHY device during the probe callback. The driver
>> >> >> creates a Rust device object to wrap the C pointer to the C's device
>>
Hi,
On Thu, 30 May 2024 04:01:39 +0200
Danilo Krummrich wrote:
> On Thu, May 30, 2024 at 08:28:24AM +0900, FUJITA Tomonori wrote:
>> Hi,
>>
>> On Wed, 29 May 2024 21:57:03 +0200
>> Greg KH wrote:
>>
>> >> For a Rust PHY driver, you know that
Hi,
On Wed, 29 May 2024 21:57:03 +0200
Greg KH wrote:
>> For a Rust PHY driver, you know that you have a valid pointer to C's
>> device object of C's PHY device during the probe callback. The driver
>> creates a Rust device object to wrap the C pointer to the C's device
>> object and passes it t
On Tue, 28 May 2024 14:19:24 +0200
Danilo Krummrich wrote:
> On Tue, May 28, 2024 at 08:01:26PM +0900, FUJITA Tomonori wrote:
>> On Mon, 27 May 2024 21:22:47 +0200
>> Danilo Krummrich wrote:
>>
>> >> > +/// Abstraction around a C firmware struct.
>&g
Hi,
On Tue, 28 May 2024 14:45:02 +0200
Greg KH wrote:
> On Tue, May 28, 2024 at 02:19:24PM +0200, Danilo Krummrich wrote:
>> However, if you have a driver that needs the firmware abstractions, I would
>> be
>> surprised if there were any hesitations to already merge the minimum device
>> abstra
On Mon, 27 May 2024 21:22:47 +0200
Danilo Krummrich wrote:
>> > +/// Abstraction around a C firmware struct.
>> > +///
>> > +/// This is a simple abstraction around the C firmware API. Just like
>> > with the C API, firmware can
>> > +/// be requested. Once requested the abstraction provides dir
Hi,
On Tue, 28 May 2024 08:40:20 +
Zhi Wang wrote:
> On 27/05/2024 22.18, Danilo Krummrich wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On Tue, May 21, 2024 at 08:32:31AM +0300, Zhi Wang wrote:
>>> On Mon, 20 May 2024 19:24:19 +0200
>>> Danilo Krummrich wrot
Hi,
On Wed, 22 May 2024 09:37:30 +0200
Philipp Stanner wrote:
>> > +/// Abstraction around a C firmware struct.
>> > +///
>> > +/// This is a simple abstraction around the C firmware API. Just
>> > like with the C API, firmware can
>> > +/// be requested. Once requested the abstraction provides
Hi,
Thanks for working on the firmware API!
On Mon, 20 May 2024 19:24:19 +0200
Danilo Krummrich wrote:
> Add an abstraction around the kernels firmware API to request firmware
> images. The abstraction provides functions to access the firmware
> buffer and / or copy it to a new buffer allocated
On Wed, 19 Oct 2011 18:19:22 -0400
Konrad Rzeszutek Wilk wrote:
> As a mechanism to detect whether SWIOTLB is enabled or not.
> We also fix the spelling - it was swioltb instead of
> swiotlb.
>
> CC: FUJITA Tomonori
> [v1: Ripped out swiotlb_enabled]
> Signed-off-by:
On Wed, 19 Oct 2011 18:19:22 -0400
Konrad Rzeszutek Wilk wrote:
> As a mechanism to detect whether SWIOTLB is enabled or not.
> We also fix the spelling - it was swioltb instead of
> swiotlb.
>
> CC: FUJITA Tomonori
> [v1: Ripped out swiotlb_enabled]
> Signed-off-by:
On Thu, 29 Sep 2011 16:33:47 -0400
Konrad Rzeszutek Wilk wrote:
> As a mechanism to detect whether SWIOTLB is enabled or not.
> We also fix the spelling - it was swioltb instead of
> swiotlb.
>
> CC: FUJITA Tomonori
> [v1: Ripped out swiotlb_enabled]
> Signed-off-by:
On Thu, 29 Sep 2011 16:33:47 -0400
Konrad Rzeszutek Wilk wrote:
> As a mechanism to detect whether SWIOTLB is enabled or not.
> We also fix the spelling - it was swioltb instead of
> swiotlb.
>
> CC: FUJITA Tomonori
> [v1: Ripped out swiotlb_enabled]
> Signed-off-by:
- it was swioltb instead of
> swiotlb.
>
> CC: FUJITA Tomonori
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> drivers/xen/swiotlb-xen.c |2 +-
> include/linux/swiotlb.h |7 ++-
> lib/swiotlb.c |5 +++--
> 3 files changed, 10 insertion
- it was swioltb instead of
> swiotlb.
>
> CC: FUJITA Tomonori
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> drivers/xen/swiotlb-xen.c |2 +-
> include/linux/swiotlb.h |7 ++-
> lib/swiotlb.c |5 +++--
> 3 files changed, 10 insertion
On Thu, 24 Jun 2010 21:51:40 +1200
Michael Cree wrote:
> >> Is this a regression (what kernel version worked)?
> >>
> >> Seems that the IOMMU can't find 128 pages. It's likely due to:
> >>
> >> - out of the IOMMU space (possibly someone doesn't free the IOMMU
> >> space).
> >>
> >> or
> >>
> >>
On Thu, 24 Jun 2010 10:53:52 -0400
Matt Turner wrote:
> > Seems that the IOMMU can't find 128 pages. It's likely due to:
> >
> > - out of the IOMMU space (possibly someone doesn't free the IOMMU
> > space).
> >
> > or
> >
> > - the mapping parameters (such as align) aren't appropriate so the
> >
On Thu, 24 Jun 2010 21:51:40 +1200
Michael Cree wrote:
> >> Is this a regression (what kernel version worked)?
> >>
> >> Seems that the IOMMU can't find 128 pages. It's likely due to:
> >>
> >> - out of the IOMMU space (possibly someone doesn't free the IOMMU
> >> space).
> >>
> >> or
> >>
> >>
On Thu, 24 Jun 2010 10:53:52 -0400
Matt Turner wrote:
> > Seems that the IOMMU can't find 128 pages. It's likely due to:
> >
> > - out of the IOMMU space (possibly someone doesn't free the IOMMU
> > ?space).
> >
> > or
> >
> > - the mapping parameters (such as align) aren't appropriate so the
> >
On Mon, 21 Jun 2010 17:19:43 -0400
Matt Turner wrote:
> Michael Cree and I have been debugging FDO bug 26403 [1]. I tried
> booting with `radeon.test=1` and found this, which I think is related:
>
> > [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0x202000
> > [drm] Tested GTT->VRAM an
On Mon, 21 Jun 2010 17:19:43 -0400
Matt Turner wrote:
> Michael Cree and I have been debugging FDO bug 26403 [1]. I tried
> booting with `radeon.test=1` and found this, which I think is related:
>
> > [drm] Tested GTT->VRAM and VRAM->GTT copy for GTT offset 0x202000
> > [drm] Tested GTT->VRAM an
23 matches
Mail list logo
