Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1399001imm; Tue, 3 Jul 2018 10:24:30 -0700 (PDT) X-Google-Smtp-Source: AAOMgpccA/WOocffeSvJ45IFfC4ZMMNHqRAkFK5lIHghbaMzpStwkri+jIpkidhZOeBl0CNp/ZhQ X-Received: by 2002:a62:c918:: with SMTP id k24-v6mr30618298pfg.160.1530638670742; Tue, 03 Jul 2018 10:24:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530638670; cv=none; d=google.com; s=arc-20160816; b=lpo4HyBCDGQMKGYWEE6uDz8/qcwDyd7VW5GqdRl3enVrZVqKsJB9uCIba+DUtQfraY zKJqh6n/ot70VeVl04RDyMfI69ll8Go1ZpjmBFZlsdbxS6zj7uB2BNJbGVtT6IsKbGjU vT/35LDDCJdCQCe9kIZBb5kTFIpgRc4EPFNLiVLgoi+3NEoBynowZdlmhtwH3PsI8n8A VBQPAHyLq8vJWeeiJaclTSSgX1kO4d+zGZCzkR4fCt4g9Wlvr3X6pOYo+SMikaEzTqme a5m5NQcyV0OVdejMNiUIat9LTkAFB9wPu+1oG82Oh00xkD04uNrx/p+vCPEObzpumZ5M dDXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=KB0kVcN2+vfhDaecoqYEyrk7Vrhc2806tNrL0U77vyU=; b=tWvhsar42NNu5kZzrdZrUyRtGaSrBgbb8axcbugWboGuhBUlul07wijGHB+PuDNZ2j 25DrcsrwMez93o37/ViyI2XDBbmCY4AU3vOlTl3Ggrv/A/JgilW7w9XlBe8+puChlvpB 3lySvrsdDJzeUXp+i5V3iB01tD5Xj1S2vaQeYl4xJ8cPV7VHNRFStxttb/9WVRaYftXO tK9qJRHOI5Hg9w4kq4xqVte/Bc3nDsvYt4NzuTHixr2qnRP4aWJDOsXDSqubPe0kTpDA 96XmzyOaRfTGoGCMvaJea+Uncn0UWwLewSqRQ7cqfIC3DggLT67qI9TPr/iKnHRAjzNM VZXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=itWuCJce; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s84-v6si1588240pfd.288.2018.07.03.10.24.15; Tue, 03 Jul 2018 10:24:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=itWuCJce; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934323AbeGCRXh (ORCPT + 99 others); Tue, 3 Jul 2018 13:23:37 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:52166 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934295AbeGCRXb (ORCPT ); Tue, 3 Jul 2018 13:23:31 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w63HNUtE184986 for ; Tue, 3 Jul 2018 17:23:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=corp-2017-10-26; bh=KB0kVcN2+vfhDaecoqYEyrk7Vrhc2806tNrL0U77vyU=; b=itWuCJce6HZjbVoTd2dxsaX1tCiU7F+b92WFa8GDIi6RbC9PeXZVj2L5MYNtEZ9QlC+m WzXpdMGUf5cIdKgc9iIRaTsCapXxlLo57ONv4tyqBgCQkAvXwvOf7yebwzlUvrYIDWYH u6gKyNWnWlEJAArnTwOqnd5nG5RpTIQ3I8g1sVo2/rH+y9No9lTmlvpdIGg/s6Ww+E14 iBsVD8ZmDzhBsmboZl/YvT3EO+ninoYaoaB7phmpTVTq8XOkmZvcyzSh182eamv8NKEu nlKIrWf+Ltm1akiYuWu21m1o28tYXzo7SLrfvuUxRtySKku6AjkLsig7g7ewhAGtexge 6w== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2jx2gq1fq2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 03 Jul 2018 17:23:30 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w63HNTXQ022224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 3 Jul 2018 17:23:29 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w63HNS9W009119 for ; Tue, 3 Jul 2018 17:23:29 GMT Received: from mail-oi0-f49.google.com (/209.85.218.49) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 03 Jul 2018 10:23:28 -0700 Received: by mail-oi0-f49.google.com with SMTP id k81-v6so5366096oib.4 for ; Tue, 03 Jul 2018 10:23:28 -0700 (PDT) X-Gm-Message-State: APt69E3QsMdIEwH0MXfFv0D5ZEJPGfgbD0Cc/W4zjph3+eRSAbOBsh30 iQngMJfziVPfM67LO4DGKHfdGcplclkcjwFSR/4= X-Received: by 2002:aca:db0a:: with SMTP id s10-v6mr23120733oig.339.1530638608445; Tue, 03 Jul 2018 10:23:28 -0700 (PDT) MIME-Version: 1.0 References: <1530637506-1256-1-git-send-email-rppt@linux.vnet.ibm.com> In-Reply-To: <1530637506-1256-1-git-send-email-rppt@linux.vnet.ibm.com> From: Pavel Tatashin Date: Tue, 3 Jul 2018 13:22:52 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/memblock: replace u64 with phys_addr_t where appropriate To: rppt@linux.vnet.ibm.com Cc: Andrew Morton , Linux Memory Management List , LKML , mhocko@kernel.org, willy@infradead.org Content-Type: text/plain; charset="UTF-8" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8943 signatures=668704 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=10 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=549 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030198 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 3, 2018 at 1:05 PM Mike Rapoport wrote: > > Most functions in memblock already use phys_addr_t to represent a physical > address with __memblock_free_late() being an exception. > > This patch replaces u64 with phys_addr_t in __memblock_free_late() and > switches several format strings from %llx to %pa to avoid casting from > phys_addr_t to u64. > > CC: Michal Hocko > CC: Matthew Wilcox > Signed-off-by: Mike Rapoport Looks good. Reviewed-by: Pavel Tatashin One minor thing that I would like to change in memblock.c is the useage phys_addr_t for size. I understand the reasoning behind this choice, but could we do something like: typedef phys_addr_t phys_size_t; It would be similar to resource_size_t. I just think the code and function prototypes would look better with proper typing. Thank you, Pavel