From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D869C5ACD6 for ; Wed, 18 Mar 2020 17:10:19 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C660220753 for ; Wed, 18 Mar 2020 17:10:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=kroah.com header.i=@kroah.com header.b="Lnl3fEAj"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="IhBemTMk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C660220753 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kroah.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.92.3) (envelope-from ) id 1jEcCU-0006Dn-9C; Wed, 18 Mar 2020 13:09:50 -0400 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jEcCQ-0006Df-QA for kernelnewbies@kernelnewbies.org; Wed, 18 Mar 2020 13:09:47 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3CF593F6; Wed, 18 Mar 2020 13:09:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 18 Mar 2020 13:09:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=ZYkS//LPr7Y+zUmtbH34B3rEN0W pld1Xh/TG26IfqE8=; b=Lnl3fEAjJZpG0z3Y+juZxZAXR+wDTPuXOJsRhEX2vv0 BsB8tJCsD2qwiqQPdU3knOBVU82OjdfQkkDClS2nP444a5C4qQUC6nPWbmv9Y9dc sArxcs1zH/0L1+zl01QTntf8ewkFefrvRZ9amg0UZB8KA8ltQocsAYOo8sg6/WG8 RuLH5EEBE/gFfnTnSKPZYZdN18Ad+Y3DExbQaMGwhvhDttQK/1B6L1UPDe3B5r7+ 9Ry7wSE/Vv7CpQSl+F0q48A/YR7N8WCoVI5m5Q++fhEi6xmVzfl5dWNIx3lWPVgk jkNMDi3HNb6RQiKs35gPh8BoOlELY61J8rawCFajQyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ZYkS// LPr7Y+zUmtbH34B3rEN0Wpld1Xh/TG26IfqE8=; b=IhBemTMkPNxB7WJ9I1U3jd lfS4oxE5/LEh2odTemfu3dNcNX8L18sqi6LdnFy9wqZtJubgyUoOBw9bxQafDi0E rtl4mEZuU8lhTGjGWDMHM+fIVLDXKotLZ3pd+caPyaGKVbh3234Nc/TJ96gX3Zzm ON1ChF+KMQHHeMi1bc/64tTKQ3Vox9Mxm+U1KU3UoQfhUY0U4ffVizgEKAnXd+x7 tyh6eMzkh2CEQnmdVu3i7WoUAWUVv4KcIhNQHSgonj769FPYSIJ/2xv7H/vwMlBI IdWS7/gQ8EkJStM1SxJIYaLKVNzoIGR+vnEc7rZMFWSobsAfrwDvOmRJGxXNnfFg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefirhgvghcu mffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucfkphepkeefrdekiedrkeelrddutd ejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghhr vghgsehkrhhorghhrdgtohhm X-ME-Proxy: Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) by mail.messagingengine.com (Postfix) with ESMTPA id 2A0A3328005A; Wed, 18 Mar 2020 13:09:39 -0400 (EDT) Date: Wed, 18 Mar 2020 18:09:37 +0100 From: Greg KH To: Lucas Tanure Subject: Re: request_firmware in DMA region Message-ID: <20200318170937.GA3110553@kroah.com> References: <06892b25-65bb-0379-da42-cbae5cbfce38@linux.com> <20200318144631.GB2860387@kroah.com> <52f381bd-d2cf-c109-6258-c73b06d4b113@linux.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <52f381bd-d2cf-c109-6258-c73b06d4b113@linux.com> Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Wed, Mar 18, 2020 at 04:55:47PM +0000, Lucas Tanure wrote: > On 2020-03-18 14:46, Greg KH wrote: > > On Wed, Mar 18, 2020 at 02:29:24PM +0000, Lucas Tanure wrote: > > > Hi, > > > > > > I'm sending firmware to usb device with this code: > > > But it`s falling because the request firmware call didn't put my firmware in > > > a DMA capable area. That's my guess. > > > > > > So how to request firmware in DMA capable area? > > kmalloc your buffer used for USB transfers. > Thanks, worked. > > > > Do you have a pointer to your driver anywhere? The code you show below > > isn't in any kernel source that I can see. > > I`m working to get permission for that. It will have to happen eventually, might as well do it now so that you can get help with it :) > Quick question: Why my usb driver doesn't unload after I disconnected it ? Who knows, we can't see the code, odds are there is a bug somewhere. > This driver is meant to load a new firmware into the board only. And after > the bootloader finished the download the board with show it self with a > different vendor and product id. > > All the firmware download in done in probe, so there is no need for this > driver after that. Can my driver unload it self ? Why do you need a kernel driver at all, you can do all of that from userspace using libusb today. And no, a driver can not unload itself, but it does not have to bind to a device if you don't want to, which should keep it from ever actually sticking to a device after the probe call has returned. thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies