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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 A7038C04AA8 for ; Tue, 30 Apr 2019 11:45:37 +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 52B2A21670 for ; Tue, 30 Apr 2019 11:45:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 52B2A21670 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=metamail.co Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.91) (envelope-from ) id 1hLRCD-0007LK-5k; Tue, 30 Apr 2019 07:45:13 -0400 Received: from s1.ubiqiti.net ([45.56.103.136]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hLRCA-0007LE-Ml for kernelnewbies@kernelnewbies.org; Tue, 30 Apr 2019 07:45:10 -0400 Received: from s1.ubiqiti.net (localhost [127.0.0.1]) by s1.ubiqiti.net (Postfix) with ESMTP id C407E6008B for ; Tue, 30 Apr 2019 11:45:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at s1.ubiqiti.net Received: from s1.ubiqiti.net ([127.0.0.1]) by s1.ubiqiti.net (s1.ubiqiti.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uDn7ak5U10kj for ; Tue, 30 Apr 2019 11:45:08 +0000 (UTC) Received: from I71607 (unknown [IPv6:2a00:23c3:3780:8600:948b:620:4a56:c9d0]) by s1.ubiqiti.net (Postfix) with ESMTPSA id 3A1F060082 for ; Tue, 30 Apr 2019 11:45:07 +0000 (UTC) From: To: Subject: debugfs question ... Date: Tue, 30 Apr 2019 12:45:08 +0100 Message-ID: <009001d4ff4a$2ac6a030$8053e090$@metamail.co> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdT/RmouIu6VDh+wTJOYZs03rbp1ig== Content-Language: en-gb 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 Greetings, My I2C sensor driver has a debugfs entry for development purposes. Everything works fine with the exception of the read operation. When 'cat' is used, the read operation is called repeatedly and indefinitely. If the read() is changed to return 0 then, as expected, nothing is displayed. The pattern for the implementation is (AFAICT) right out of the book (shown below). What am I missing? Any thoughts much appreciated. TAIA. RDQ static ssize_t sc031gs_reg_read_file(struct file *file, char __user *user_buf, size_t count, loff_t *ppos) { char *buf = 0; ssize_t total = 0; struct sc031gs_dev *sensor = file->private_data; if (!sensor) return -EINVAL; if (*ppos < 0 || !count) return -EINVAL; buf = kmalloc(count, GFP_KERNEL); if (!buf) return -ENOMEM; total = snprintf(buf,count,"Hello world\n"); if (total >= 0) { if (copy_to_user(user_buf, buf, total)) { kfree(buf); return -EFAULT; } *ppos += total; } kfree(buf); return total; } _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies